Hi Werner,
I have experienced the same scenario several times also and the only thing that I now always do is, have an active Link-Alive process in place. The client will expect some data in a certain time interval (e.g. 60 sec) and if it does not get data, closes connection and re-opens again. The server sends a link alive message when no other message is available to send e.g. after 45 sec. The server will at some point detect that the client is no longer there because the send will fail.
This process has solved all my problems I had with not detecting link down.
The low level link alive on the socket never worked as expected, independently of the operating system (Windows / Linux)

Best regards

Thomas


Am 06.07.2017 um 22:36 schrieb Werner Hauptfleisch:
Hi,

I have been trying to resolve the following scenario (using the TCP Server Echo example)

1. The TCP Server Deamon in the echo example runs as normal and accepts a client connection (such as a client connection via telnet from a different PC on the network)
2. The client connection is accepted and the TCPEchoThread is started
3. I have changed the code a little, so once the client has sent some data the server continues to send data to the client until the connection is stopped by the client, for example:

with sock do
begin
   repeat
          if terminated then break;
          s := RecvPacket(10000);
          while lasterror = 0 do
          begin
                if CanWrite(1) then
 SendString('Testing connection...' + #13#10)
                else
Writeln('Cannot send');

                if lastError<>0 then break;
Sleep(500);
          end;
   until false;
end;

The code above works fine and when the client connection terminates the value of sock.lasterror is set and the client thread can terminate.

The problem comes with the following scenario:
1. Instead if stopping the client side application, pull the network cable from the client PC - this seems to terminate fine and lasterror is populated on the server side (and client detects the same error)
2. This is the main problem scenario:
- Connect from a client on a virtual pc (using Oracle Virtual Box for example), and whilst the socket connection is in place, simply disable the network interface on the virtual pc.
     - Observations are:
a. the client side on the virtual pc detects the error and stops (most of the time) b. The server side seems to never detect that the client is disconnected, and continues to send data without lasterror being set at all and it waits for a very long time before disconnecting finally c. using a tool such a netstat, it is noted that data continues to be added to the TCP buffer for the socket connection, which remains in a ESTABLISHED state - This same scenario can be simulated across the internet when the link is unstable / unreliable or routers and switches start failing

I have attempted to resolve this by setting kernel parameters, and various options available from the documentation. None worked up till now.

So the question is:
A, Using the scenarios above where the socket is being interfered with as described, how can the server side detect the that the client connection is actually not there and terminate the client thread? B. Do I have to set some additional socket options at the server, and if so, which options needs to be set?

Many thanks in advance!

W


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org!http://sdm.link/slashdot


_______________________________________________
synalist-public mailing list
synalist-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/synalist-public

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
synalist-public mailing list
synalist-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/synalist-public

Reply via email to