Hello, I am facing one issue when Server initiate FIN first. Having FIN, Client sending ACK and then in another packet Client is sending PSH+ACK. This PSH (data) server unable to read or capture. Here is the MSG flow in our case. 4343: ------------FIN---------> (from SAP, Server) 4345<-------------ACK--------- (from EMA, Client) 4347<----------PSH,ACK------- (From EMA, Client) 4349<---------FIN,ACK--------(From EMA, Client) 4351-------------RST--------->(From SAP, Server) 4352------------RST--------->(From SAP,Server) I would like to know sending PSH+ACK after (FIN) and acknowledging the same is standard or not. Why Server is not able to read this PSH data? asked 06 Jun '16, 01:51  Isme Azam |
One Answer:
Posting screenshots is discouraged since it makes investigating a problem really hard. If possible can you share a capture in a publicly accessible spot, e.g. CloudShark? From the description it seems that the server doesn't handle closing the TCP connection gracefully. Since the TCP connection is bi-directional both ends have to finish the connection once all data has been exchanged (both ways). When that is is decided by each end individually, hence the FIN flag going both ways. In this case the server terminates the TCP connection, without letting the client close the connection on it's own. The last data from the client, before it closes its end of the connection, can no longer be received by the server, as it terminated the connection instead of just closing its end. I would say the relevant socket in the server application is shutdown() instead of close()ed. answered 06 Jun '16, 02:21  Jaap ♦ Please find the TCPDUMP from below location. https://www.cloudshark.org/captures/e5cc26206a6b How to improve this situation? please suggest. Is it good idea if we use timeout value (in server side which would be greater than client end)? or is there any mechanism where only Client shall initiate close the connection? (06 Jun '16, 02:39) Isme Azam After de-duplication the TCP flow is obvious, the server shuts down the connection leaving the client out to dry. As for the reason why the server does this, and what the client has to report at the end, and what to do with that is up to the application developers. (06 Jun '16, 04:03) Jaap ♦ |
Please review and share any kind of feedback. This issue is burning my life.