Socket and ttl

  • Thread starter Thread starter Brandon
  • Start date Start date
B

Brandon

I am trying to use a UDP broadcast in C# to basically publish a stream of
data to any number of processes running on the local machine that care to
listen in - and I do not want this broadcast getting off of the machine onto
the network. It should be noted that I test on the full framework first,
because of the higher visibility and simpler IP routing situation. At first
this question may not sound like it belongs on this particular board, but
bear with me - some of this is just background to answer questions that I
know will be asked:

My first thought was to broadcast to 127.0.0.1, and this works fine except
that it seems that only one process can listen at a time... process A will
be receiving the stream, and as soon as process B binds, process B starts
receiving the stream and process A is just blocking, then as soon as process
B unbinds, process A picks up the stream again. And I am using
Socket.SetSocketOption(SocketOptionLevel.Socket,
SocketOptionName.ReuseAddress, true);

So the next thing I tried was to broadcast to 255.255.255.255 with a
Socket.Ttl of 0. This works exactly how I want it to - both process A and B
running local receive the stream of data simultaneously, while process C
which was running on a different machine on the same ethernet segement did
not. Unfortunately, when I went to port this over to the compact framework
(2.0), I found that Socket.Ttl does not exist... How do you set the TTL on
the compact framework? On the full framework, I tried
Socket.SetSocketOption(SocketOptionLevel.Socket,
SocketOptionName.IpTimeToLive, 0), which is available on the compact
framework, but it did not keep the broadcast off of the network (process C
running on a different box on the same ethernet segment received the
broadcast).

Thanks in advance for any tips you might have.
 
[...]
My first thought was to broadcast to 127.0.0.1, and this works fine except
that it seems that only one process can listen at a time
[...]

So the next thing I tried was to broadcast to 255.255.255.255 with a
Socket.Ttl of 0. This works exactly how I want it to
Click to expand...

Something in between these approaches would be to send to
127.255.255.255, which is the broadcast address for the local network.

Haven't tried it, but it may be worth a shot.

Good luck,

----Scott.
 
I had tried 127.0.0.255, and 127.0.255.255, but not 127.255.255.255 ... With
the former two, the local processes block eachother, just like when I used
127.0.0.1, but for some reason the latter does not - both processes recieve
the messages simultaneously. Can anyone explain this?

Scott Gifford said:
[...]
My first thought was to broadcast to 127.0.0.1, and this works fine except
that it seems that only one process can listen at a time
[...]

So the next thing I tried was to broadcast to 255.255.255.255 with a
Socket.Ttl of 0. This works exactly how I want it to
Click to expand...

Something in between these approaches would be to send to
127.255.255.255, which is the broadcast address for the local network.

Haven't tried it, but it may be worth a shot.

Good luck,

----Scott.
Click to expand...
 
Brandon said:
I had tried 127.0.0.255, and 127.0.255.255, but not 127.255.255.255
... With the former two, the local processes block eachother, just
like when I used 127.0.0.1, but for some reason the latter does not
- both processes recieve the messages simultaneously. Can anyone
explain this?
Click to expand...

Sure, 127.255.255.255 is the network-local broadcast address for
127.0.0.0/255.0.0.0, just like 255.255.255.255 is the network-wide
broadcast address. 127.0.255.255 and 127.0.0.255 are just normal
addresses that happen to have a 255 in them, which is why they don't
have any special behavior.

When multiple processes are listening on a local UDP socket and a
packet comes in, one of the processes is given the packet. This
allows multi-process servers to load balance (for example a DNS server
could use multiple processes to reduce latency; Apache uses this
feature with TCP sockets when run with the multiple-process model).
When a broadcast packet comes in, all of the processes get the packet.
This is true on Unix at least; apparently it's at least similar on
Windows and WinCE.

Hope this helps,

----Scott.
 
Back
Top