socket connection is getting terminated

[Amit K]

We are trying to upload a file from one solaris box to HP UX 11.11 server using TCP communication.
if we try to upload the file 5 times. connection is getting timed out 3 times.
As per application team; they suspect that the socket connection is getting terminated.
--------------------------------------
"when it receives data on the same socket, it sends a TCP RST with cause "new data received when detached". The issue here is that the remote side (Portal) does not send a FIN segment to gracefully terminate the connection"
this is an intermittent behavior.

Can anybody help me on this?

I had also attached trace logs. Please check the same.

[Matti_Kurkela]

Please see:
http://www.io.com/~maus/HttpKeepAlive.html

Note that "Connection: Keep-Alive" is not a guarantee that the connection stays alive even if the server confirms it.

From the trace, I see that the client specified "Connection: Keep-Alive" in the headers of the POST request. The server responded with:
...
Connection: Keep-Alive
Keep-Alive: timeout=5, max=999
...

i.e. the server tells the client it will close the connection if it remains idle for more than 5 seconds.

Timeline:

09:53:21.453750 client sends first SYN

09:53:21.453797 server sends SYN-ACK

09:53:21.464614 client sends ACK, connection
established

09:53:21.465322 client sends the first POST request

09:53:21.780387 server begins to answer the first POST

09:53:21.836317 server completes sending the first answer

09:53:25.409714 client sends the second POST request

09:53:25.687579 server begins to answer the second POST

09:53:25.699270 server completes sending the second answer

09:53:25.710783 client sends the last ACK to the second answer

!!! more than 5 seconds passes with no traffic !!!

09:53:31.690002 server sends FIN (because the Keep-Alive has timed out)

09:53:31.700706 client sends ACK, confirms it has received the FIN. (The client OS knows now the server side has closed the connection.)

09:53:33.171413 client sends a third POST request

09:53:33.171447 server sends RST because the server-side of the connection is already closed and cannot be re-opened.


The client application should have checked if the connection is still open at 09:53:33.171413 before sending the third POST. The OS knew and could have told the app that the connection was already half-closed. At this point, the application should have closed the client side of the connection and initiated a new one for the third POST.

I think the behaviour of the server application is correct according to the HTTP 1.1 specification.
The RST is justified because the TCP protocol does not allow a half-closed TCP connection to be returned to the fully-open state. The only way to proceed is to tear down the half-closed connection and set up a new one.

The client's naive expectation that the connection remains open indefinitely if "Connection: Keep-Alive" was confirmed is incorrect. In other words, there is a bug in the client side.

The client should not attempt to rely on the timeout values announced in the Keep-Alive: header. To achieve a robust behaviour, the client should be prepared to tear down and re-establish the connection at the start of each POST if the old connection is unusable for any reason.

MK

[Amit K]

Thanks MK for inputs.

I had asked application team to check POST settings from apps end.

I will revert once i get any inputs from them.

Regards
Amit K