[lnkForumImage]
TotalShareware - Download Free Software

Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

microsoft.public.dotnet.framework

UDP broadcast/receive notification system

Mark

7/18/2008 7:07:00 PM

Hi...

Didn't see another group that would be more specific for this.

I inherited from another programmer a C# class using the System.Net.Sockets
classes to implement a udp broadcast/receive notification system so that all
the machines on a subnet can keep up-to-date on events.

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?

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? Did I not get my message
back because the socket classes recognize my identity down the the process
level?

Thanks
Mark

3 Answers

Peter Duniho

7/18/2008 7:22:00 PM

0

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

Mark

7/18/2008 8:12:00 PM

0

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

Jack Jackson

7/18/2008 8:55:00 PM

0

On Fri, 18 Jul 2008 12:07:01 -0700, Mark <mmodrall@nospam.nospam>
wrote:

>Hi...
>
>Didn't see another group that would be more specific for this.
>
>I inherited from another programmer a C# class using the System.Net.Sockets
>classes to implement a udp broadcast/receive notification system so that all
>the machines on a subnet can keep up-to-date on events.
>
>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?

Unless the Sockets documentation specifically addresses this behavior,
I think it would be prudent to have code to notice this. It is
possible that this behavior is not a result of .NET code, but of code
in the OS or LAN card driver, either of which might change in the
future.