Click to See Complete Forum and Search --> : Problem: losing connections


ziune
January 6th, 2005, 06:45 AM
Hello everybody.

I have a client-server application that runs on Win32 and uses winsock 2.
The application uses overlapped IO on the socket (uses normal Read
and Write win32 functions and it is notified of the IO completion event
by a WaitForMultipleObjects on the hEvent HANDLE in the OVERLAPPED
structure).
The server listens on a public IP address whick is part of a LAN
and sends asynchronous data to the connected clients through
two connections: the first one has a data tranfer rate almost constant and
is always active; on the second one , instead, the rate at which the data
is sent is totally unpredictable.
When both connections are initiated, startup data is sent
to the client, and this data is received correctly.
The first connection gives no problem at all.
The second connection has a strange behaviour:

if a client connects from inside the LAN the connection never goes down,
while if a client connects from outside (reaching the server address through
another ISP) and the connection is idle, i.e. no data is sent by the server,
for a long time (around 10 minutes) and new data is sent
the Write function on the socket returns TRUE, the GetLasterror()
function returns 0 and the number of bytes written is set to the right
value. After that the application is notified with the FD_CLOSE event.
No notification is received by the client. If the client tries to
send data on the connection, no data is sent (of course, because
the connection does not exists anymore) and, after a while, it gets
a FD_CLOSE event notification.

Does anybody have experienced the same behaviour?
Any idea why this thing happens?
Is it possible that connections from outside have some kind of timer
that drops them down when no data is sent through?
Could it be caused by a setting in one of the routers?

Thanks in advance.

Vincenzo.

Tomcat
January 7th, 2005, 03:13 AM
If the client is behind a NAT/NAPT router it probably stops translating/forwarding the packets after less than 10 minutes. You can try setting the socket option SO_KEEPALIVE, but unfortunately that may not always work ("A Windows Sockets provider need not support the use of keep-alives. ").

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winsock/winsock/setsockopt_2.asp

Mathew Joy
January 8th, 2005, 09:59 AM
SO_KEEPALIVE socket opt allows the TCP keep alive packet to be send. In Win32 implementation the interval is 2hrs, which is the minimum recomendation in the RFC. This can be changed in the registry though. But since it is a global change, it is not usually recomended. A better one is using the ioctl command SIO_KEEPALIVE_VALS. Unfortunately this works only with w2k. Implementing your own keep-alive messages is another option.