Re: Asynch Sockets over UDP: How do you Know when a socket dissconnects
- From: Barry Kelly <barry.j.kelly@xxxxxxxxx>
- Date: Wed, 14 Jun 2006 04:09:44 +0100
"DaTurk" <mmagdits@xxxxxxxxxxx> wrote:
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
--
http://barrkel.blogspot.com/
.
- Follow-Ups:
- References:
- Prev by Date: Re: Force references to run against .NET 1.1
- Next by Date: Re: DAAB problem
- Previous by thread: Re: Asynch Sockets over UDP: How do you Know when a socket dissconnects
- Next by thread: Re: Asynch Sockets over UDP: How do you Know when a socket dissconnects
- Index(es):
Relevant Pages
|
