I have traced a TCP stream sent over my LAN. Everything runs quick until the FIN, ACK from server to client (there is a 2 second delay here). I'm not sure if the issue is server side or client side, any ideas? http://picthost.net/v.php?id=0e1b3f755b766b166e39822e4d652664 asked 24 Feb '14, 07:59  markc1 edited 24 Feb '14, 08:06 |
One Answer:
without knowing the upper layer application protocol it is hard to say. The client sends 8 bytes to the server and immediately closes the connection again. So what is in the payload and how should the server react upon the data? Obviously it just doesn't do anything and closes its end of the connection after 2 seconds (timer popping?) What exactly is 'the issue' ? answered 24 Feb '14, 10:34  mrEEde |
Thank you for the reply. The client app is a vb.net application sending data via a TCP client (I close the connection after sending). I don't monitor any responses from the server on the client app. The server is a Perle IOLAN box (converts tcp stream to serial) that basically takes the input stream and puts out via a serial port that in turn connects to a PLC. The issue is the 2 second 'lag'. It just seems strange that all AKS prior to the FIN, ACK take milliseconds and then there seems to be some delay. Maybe this is normal, I'm not sure. The whole think does work end to end but the total round trip is just taking too long. I can provide more info if this would help?
The ACKs are sent from the TCP stack whereas the FIN requires a close() socket call from the server application. So it is not too strange to see (sub-)ms responsetimes in the same ethernet LAN and a - purposely? - delayed closing of the tcp connection from the server.
So is it fair to say that the server is causing the 'delay'? I have limited control over the server side but just need to clarify that there is nothing I can do on the client side to affect the FIN?
Yes, that's right.
You can try to send a FIN and 'shortly' after that a RESET. If the server accepts that behavior (meaning it does not drop the sent data), your local socket might get closed faster (and the remote socket as well).