0

I have a service doing listen that serves clients over a TCP sockets connection with a raw binary protocol.

The principle is basic: the connection is established, the client sends a request with data, the service responds with data and the connection is closed.

Everything works fine, however there are random cases where the client stops receiving the response from the service. I noticed that these cases happen when the server starts to have a load. I made a capture of the communication between the client and the service and noticed that in the load tests, in the 6 requests that failed, the 6 have packets with flag [RST].

IP x.95.1 is the client and IP x.95.8 is the service. The image shows an example of the communication that failed, but I am not understanding correctly the handshake sequence and the reason for [RST], can someone explain to me what may be happening in this sequence? enter image description here

I need to know which side (PHP client / C++ service)has the socket problem of closing the connection when it appears that the client has done the handshake correctly and then sent the request data, and the reason that they exist these RST packages.

I appreciate some tips. Thanks

Improve this question
3
  • Unfortunately, questions about hosts/servers are off-topic here. The above linked question has an answer that explains the TCP RST. We cannot help debug your application. You could try to ask about that on Stack Overflow, but they are going to want to see some code.
    – Ron Maupin ♦
    Apr 20, 2021 at 12:00
  • Thanks @RonMaupin for pointing out a great explanation about RST packets! Reading your link and looking at the image with the sequence of packets, it made me think that what is happening is that at No. 5656 the server sends a [FIN, ACK] to initiate a close of the connection, to which the client responds at No.5659 [ACK]. However, the same client then sends at No.5687 [PSH, ACK] with the data. This does not seem correct, since the closing process had started, so the service responds [RST]. Is my reading of the sequence right?
    – Ariel
    Apr 20, 2021 at 13:22
  • Well, one side sending a FIN just means it is done sending, but it is still obligated to listen and process anything from the other side until the other side also sends a FIN. There is a diagram in the RFC that shows the whole state machine process.
    – Ron Maupin ♦
    Apr 20, 2021 at 13:33

0

Reset to default

Browse other questions tagged or ask your own question.