Socket events in vb.net compact framework

[Guest]

Hi All,

I am developing a Client / Server App using Visual Studio 2003 and a Smart
Device App and a TCP/IP Socket connection.

I have discovered a major flaw in the Winsock2 implementation in .Net
framework that I have no work around for.

The issue is there are no events or work arounds (that work) for capturing
when a client socket goes away. The issue is also inherent in the server
side also for sending data. You don't know the socket has closed server side
until an attempt to send is made. The server problem is not that much of an
issue just annoying, as the client maintains the connection on our CDMA/GPRS
networks. With data being at a premium for this service, sending heartbeats
at short intervals for over 200 devices gets very expensive. If the socket
was to alert the client app when it is closed the client can then reconnect
and maintain a reliable efficient connection for message delivery.

Suggested work around (Does not work)

Using the asycronous callback for begin receive (which I alread was), if
you fail to receive data in the callback function, the socket has most likely
gone away and you should test for reconnection. Unfortunately the callback
function is not called with 0 bytes received so there is no way to know the
connection has been dropped.

Does anyone have another work around that they have tested or is this a wait
until next version of winsock issue and hope something else has not been ?

This seams to me to be a fundamental flaw in the .net framework
implementation of winsock2 and one you would definately hope gets fixed asap.

Any help anyone could provide would be much appreciated.

Thanks,

Glen.

 

[Paul G. Tobey [eMVP]]

I don't think it has anything to do with .NET CF. That's the way Winsock
actually works. In C, the best way on the receiving end of a connection to
detect a cleanly-closed socket is to use select() to decide when the socket
is ready to read. When it's ready, you do a recv() to get the data. If the
number of bytes returned is zero, the socket was closed by the other end of
the connection.

send(), obviously, handles this just fine by itself because there's an
action in progress that will not be acknowledged by the other end, if the
socket is gone.

Are we talking about a clean close of the socket or a loss of network
connectivity?

Paul T.

 

[Guest]

Hi Paul,

Thanks for the response.

The compact framework has alot to do with it due to the functionality of the
winsock2 implementation being cut down in it.

I am talking about ANY loss of connection due to network error and also
server closed connection. And as per my previous reponse the zero byte
return of begin recieve is not fired on disconnection of the network or
nework error.

Thanks,

Glen.

 

[Paul G. Tobey [eMVP]]

Server connection close can be detected as I mentioned in my last message.
Clean disconnect works fine and is detected as soon as is reasonably
possible.

Loss of network continuity because of a cable cut somewhere out there is
simply not something that is easily detected. Keep-alive is the only
standard method of detecting it and there is no simple fix (or the IETF
would have added it a long time ago). The reason you don't get a zero byte
receive in this case is that the system doesn't know that the connection is
broken and, I'd claim, that there's no way for it to know any better than it
does. How would it detect the difference between simply not receiving any
messages from the other end because the other end isn't sending any and the
case where the cable was cut? The only way to do that is for you to put
some semantics around it to tell it that it must expect X or Y and, if it
doesn't get it, assume that the pipe is broken somewhere.

Paul T.