CODEWITHSUNDEEP
socketsnetwork-programmingtcp
boot4life
boot4life

Reputation: 5324

Can we just reset TCP connections after an application level acknowledgement has been received?

I'm investigating resetting a TCP connection as a solution to the TIME_WAIT issue.

Let's use the following request-reply protocol as an example:

  1. The client opens a connection to the server.
  2. The client sends a request.
  3. The server replies.
  4. The server closes.
  5. The client closes as well.

This causes a TIME_WAIT state at the server. As a variation, the client could close first. Then, the TIME_WAIT lands on the client.

Can we not replace steps 4 and 5 by the following?

  1. The client resets.
  2. The server resets in response to the incoming reset.

This seems to be a way to avoid the TIME_WAIT issue. The server has proven that it received and processed the request by sending its reply. Once the client has the reply the connection is expendable and can just go away.

Is this a good idea?

Upvotes: 1

Views: 469

Answers (2)

Kaz
Kaz

Reputation: 58598

The only problem is that the server doesn't know whether the client received everything. The situation is ambiguous: did the client connection reset because the client received the whole reply, or was it reset for some other reason?

Adding an application level acknowledgement doesn't reliably fix the problem. If the client acknowledges, and then immediately closes abortively, the client can't be sure that the server received that acknowledgement, because the abortive close discards untransmitted data. Moreover, even if the data are transmitted, it can be lost since the connection is unreliable; and once the connection is aborted, the TCP stack will no longer provide re-transmissions of that data.

The regular, non-abortive situation addresses the problem by having the client and server TCP stacks take care of the final rites independently of application execution.

So, in summary, the aborts are okay if all we care about is that the client receives its reply, and the server doesn't care whether or not that succeeded: not an unreasonable assumption in many circumstances.

I suspect you are wrong about the TIME_WAIT being on the server.

If you follow the following sequence for a single TCP-based client-server transaction, then the TIME_WAIT is on the client side:

  1. client initiates active connection to server

  2. client sends request to server.

  3. client half-closes the connection (i.e. sends FIN)

  4. server reads client request until EOF (FIN segment)

  5. server sends reply and closes (generating FIN)

  6. clients reads response to EOF

  7. client closes.

Since client was the first to send the FIN, it goes into TIME_WAIT.

The trick is that the client must close the sending direction first, and the server synchronizes on it by reading the entire request. In other words, you use the stream boundaries as your message boundaries.

What you're trying to do is do the request framing purely inside the application protocol and not use the TCP framing at all. That is to say, the server recognizes the end of the client message without the client having closed, and likewise the client parses the server response without caring about reading until the end.

Even if your protocol is like this, you can still go through the motions of the half-close dance routine. The server, after having retrieve the client request, can nevertheless keep reading from its socket and discarding bytes until it reads everything, even though no bytes are expected.

Upvotes: 1

Gil Hamilton
Gil Hamilton

Reputation: 12347

I would say: No it's not a good idea. Every possible solution ends up with the same "problem" that TIME_WAIT ultimately addresses: how does party A, acknowledging the ending of the connection (or acknowledging the other side's final acknowledgment of the ending of the connection), know that party B got the acknowledgment? And the answer is always: it can't ever know that for sure.

You say:

the server has proven that it received and processed the request by sending its reply

... but what if that reply gets lost? The server has now cleaned up its side of the session, but the client will be waiting forever for that reply.

The TCP state machine may seem overly complicated at first glance but it's all done that way for good reason.

Upvotes: 1

Related Questions