|
|
|
date: Fri, 18 Jul 2008 12:07:01 -0700,
group: microsoft.public.dotnet.framework
back
Re: UDP broadcast/receive notification system
On Fri, 18 Jul 2008 12:07:01 -0700, Mark <mmodrall@nospam.nospam> wrote:
> [...]
> In his classes, he prefaces each broadcast message with a guid so that
> when
> a message comes in he can check to see if it's one he just sent. This
> spurred a couple of questions for me:
> 1) I haven't yet seen a message I drop on the broadcast address come
> back on
> my receiver socket. Was this just speculative overkill on his part?
Are you sure that's all he's using it for? He may be also (or instead)
using the GUID to detect duplicated datagrams at the recipient end.
My recollection is that the sending socket won't get echos, so if that's
all he's doing, yes...that's probably overkill. But it's possible that's
not all he's doing.
> 2) Now I know this sounds a little daft, but he purposely set it up so
> that
> multiple processes on the same box can both broadcast and receive.
> Would I
> see the message coming from my box on one of the other processes (if I
> get
> one started up) that's listening on the same port?
Unless you bind to different IP addresses, you wouldn't be able to receive
on the same port (I prefer not to use the word "listen" when talking about
UDP, because it has a more specialized meaning in the context of TCP).
You wouldn't be able to create the socket unless you specifically say that
you want to reuse the address, and even reusing the address is not
necessarily going to allow two different sockets to both receive data on
the same port.
But yes, assuming you explicitly bind to two different IP addresses, you
could have one process send a datagram, and another process on the same
computer receive that datagram.
Pete
date: Fri, 18 Jul 2008 12:22:29 -0700
author: Peter Duniho
Re: UDP broadcast/receive notification system
Thanks for the reply, Pete...
> > [...]
> > In his classes, he prefaces each broadcast message with a guid so that
> > when
> > a message comes in he can check to see if it's one he just sent. This
> > spurred a couple of questions for me:
> > 1) I haven't yet seen a message I drop on the broadcast address come
> > back on my receiver socket. Was this just speculative overkill on his part?
>
> Are you sure that's all he's using it for? He may be also (or instead)
> using the GUID to detect duplicated datagrams at the recipient end.
>
> My recollection is that the sending socket won't get echos, so if that's
> all he's doing, yes...that's probably overkill. But it's possible that's
> not all he's doing.
Well, that's what the comment next to the code says he was trying to do. In
any case, when I run the program and cause a message to be sent, I don't see
the message come by the receiving socket in the same process.
There's one socket opened that uses IPAddress.Broadcast to do the sending,
then there's another socket opened on my ip and bound to the same port for
receiving. As you mentioned, the receiving socket has
SocketOptionName.ReuseAddress set so that other processes can open it too.
I haven't tried running up multiple processes using the same object to see
if one of the other guys would get it but the sender currently isn't...
Thanks
Mark
date: Fri, 18 Jul 2008 13:12:01 -0700
author: Mark am
|
|
