CODEWITHSUNDEEP
pythonsocketstcpudp
Haridas N
Haridas N

Reputation: 549

TCP Connection Reset by peer and Transport End Point is not connected

We are running a TCP server client architecture in a same machine, the client connects the server on 127.0.0.1:30008. What we are seeing is that some time TCP connection was getting reset by the Server. We can clearly see that on the tcpdump trace that the RST flag was sent by the server. The client code is in python, and the server code is in C.

  1. What caused server to send this RST flat ? , this setup was used to run for months without any issue, so we are surprised to see what is happening now.

  2. The TCP server getting data from other server via another UDP port, and it's getting transferred via TCP port 30008 to the client, client is listening to the server port in a while loop. Wondering, this Connection RST problems wont happen for the UDP connections right ?

  3. Some time We can see that the server is closing the socket, so client getting the exception "Transport end point closed", what caused this to happen. Client has any thing to do with this issue ?

I checked out internet to see solutions, I can only see this may be due to some router sitting between the server and the client, but in my case that's not the situation.

Please help me to figure out what is going on with the server.

EDIT- Here is the sample tcptrace (Output of "tcpdump -r actuall_trace.pcap"). tcpdump.log - You can see the RST flags at the end of the file. This file includes one entire start to end communication trace.

Thank you.

Upvotes: 2

Views: 4045

Answers (1)

MattH
MattH

Reputation: 38247

Your client localhost.36291 is responding with zero-sized accept-window, indicating to the server localhost.30008 that it cannot receive any data.

15:52:59.766558 IP localhost.30008 > localhost.36291: Flags [P.], seq 218350:227950, ack 23328, win 768, options [nop,nop,TS val 2017821166 ecr 2017821158], length 9600
15:52:59.767766 IP localhost.36291 > localhost.30008: Flags [P.], seq 23328:23362, ack 227950, win 0, options [nop,nop,TS val 2017821167 ecr 2017821166], length 34

This is probably because you've filled your receive buffer in the client and probably because you're not reading from the receive buffer until empty.

In your python code, when a select indicates there's data on a file descriptor, you must read from the file descriptor until no data is returned (buffer emptied). Set the socket non-blocking, read until EAGAIN/EWOULDBLOCK.

Upvotes: 3

Related Questions