Asynch Sockets over UDP: How do you Know when a socket dissconnects

[DaTurk]

I have this application that has one sender, and multiple receivers,
the receivers are subscribing to a multicast group to which the sender
is sending information synchronously, while the receivers are receiving
asynchronously. My issue, is that if the if the receiver's socket
disconnects for any reason I want to be able to detect it and attempt
to reconnect.

Although I'm uncertain what to look for. I thought the receiver would
receive 0 bytes, but this is only with TCP. I would also like to
implement a time out where each attempt to reconnect is stalled for
that amount of time before trying to reconnect. Any help would be
appreciated.

 

[Greg Young]

There is no such thing as a connection in UDP ..
http://en.wikipedia.org/wiki/Connectionless_protocol

Not quite sure what you are looking for?

Cheers,

Greg Young
MVP - C#
http://codebetter.com/blogs/gregyoun

 

[Barry Kelly]

I have this application that has one sender, and multiple receivers,
the receivers are subscribing to a multicast group to which the sender
is sending information synchronously, while the receivers are receiving
asynchronously. My issue, is that if the if the receiver's socket
disconnects for any reason I want to be able to detect it and attempt
to reconnect.

Although I'm uncertain what to look for. I thought the receiver would
receive 0 bytes, but this is only with TCP. I would also like to
implement a time out where each attempt to reconnect is stalled for
that amount of time before trying to reconnect. Any help would be
appreciated.

You need to send keep-alive packets of some kind. UDP is connectionless,
so there is no "connection" to detect.

-- Barry

 

[DaTurk]

Would it make sense then, since there esentially won't be any
disconnect, to just check for a SocketException, and assume that if we
catch one that the socket is unable to send receive, and attempt to
reconnect?
That's what I'm doing now, but I haven't tested it.

 

[Barry Kelly]

Would it make sense then, since there esentially won't be any
disconnect, to just check for a SocketException, and assume that if we
catch one that the socket is unable to send receive, and attempt to
reconnect?

UDP is unreliable and *connectionless*. It makes a best-effort to
deliver, but the packets may simply disappear into the ether. Any errors
you get may disappear with the next packet you send, but on the other
hand, the packets might simply have been dropped somewhere along the
way.

There is no "connection" process, so attempting to "reconnect" doesn't
actually do *anything*. That is, at the low level of the BSD socket API,
calling "connect" on a connectionless (i.e. UDP over IP) socket that you
already called "connect" on, does *absolutely* *nothing*.

The Windows API docs have this to say (connect function, Winsock):

---8<---
For a connectionless socket (for example, type SOCK_DGRAM), the
operation performed by connect is merely to establish a default
destination address that can be used on subsequent send/ WSASend and
recv/ WSARecv calls.
--->8---

There is no connection established when you call connect, and no bytes
leave your machine when you call connect.

If you *need* to know if the other application is listening, it either
has to echo your packets in some way, or send back a heartbeat of some
kind.

-- Barry

 

[DaTurk]

Thanks for the reply, I think I didn't use the correct words, when I
say reconnect, I really mean set the socket up to receive
informationfrom the given multicast group
i.e. Bind, Subscribe to MultiCast Group, BeginReceive.

Like I said, I'm just expecting a Socket exception if it happens. Then
I attempt to go through the motions to put the socket back in a
position to receive information from the Multicast group.