CODEWITHSUNDEEP
c++actionscript-3socketstcptcpdump
Jorge Fuentes González
Jorge Fuentes González

Reputation: 11805

Why TCP socket send a RST packet instead of resending data when receives an incorrect ACK?

One the 'cool' things about TPC connections is that data is not lost. When data is not ACKed, TCP supposedly resends the data.

I have a classic games server written in c++ and the client is written in Flash AS3.

In the client i've added a checker tool that tries to connect to YouTube and Twitter each X seconds with a timeout of 5 seconds. The problem is that after the internet connection of the client is broken during some seconds (Internet checker receives 1 or 2 timeouts, but after that receives OKs), it starts receiving data from the server but the server stops receiving data from the client.

This is the flow received by TCPDUMP:

1. server > client: Flags [P.], seq 2374:2378, ack 119, win 14600, length 4
2. client > server: Flags [.], ack 2374, win 15524, length 0
3. client > server: Flags [.], ack 2378, win 15520, length 0
 . [Here the client sends data to the server, but the server never receives it...]
4. server > client: Flags [P.], seq 2378:2383, ack 119, win 14600, length 5
5. server > client: Flags [P.], seq 2386:2389, ack 119, win 14600, length 3
6. client > server: Flags [.], ack 2386, win 15512, length 0
7. client > server: Flags [.], ack 2389, win 15509, length 0
8. client > server: Flags [R.], seq 127, ack 2389, win 0, length 0

As you can read, when the server send data with an incorrect ACK, the client istead of resending the data, sends a RST packet (forcing the server to close the connection). In the client log I can see that receives and process the data sent by the server (So the connection is not closed when the server sends an incorrect ACK).

When TCP decides to send a RST packet instead of resending data after receiving an incorrect ACK?

The client socket is an AS3 Socket defined this way:

var socket:Socket = new Socket();

And the server socket is set non-blocking with fcntl(). Also has this options:

setsockopt(socket, IPPROTO_TCP, TCP_NODELAY, (char *)&dummyint, sizeof(int));
setsockopt(socket, SOL_SOCKET, SO_KEEPALIVE, (char *)&dummyint, sizeof(int));

Upvotes: 4

Views: 3220

Answers (2)

Brian White
Brian White

Reputation: 8756

Note that there seems to be an additional packet missing from the dump, server bytes 2383-2385, though it seems the client did see them because it ACK'd them.

The server isn't replying with an incorrect ACK. It's replying with an ACK of the last byte-number it saw in the stream, #119. It's up to the client to retransmit those missing bytes when the server fails to ACK them after some period of time. Instead, it's sending a RST.

There's no timing information but I'd have to guess that the RST is coming from a time-out on the client before the information was due to be re-transmitted.

Upvotes: 4

mark
mark

Reputation: 5469

TCP is not "unstable" per se, it's a protocol. If anything is unstable it's your network connection. TCP has an algorithm for retrying on unstable networks. It's also possible there's something wrong with your code, and it's possible there's an intermediary device timing out your connection.

Upvotes: 2

Related Questions