TCP Sockets: "Rollback" after timeout occured

Question

This is a rather general question about TCP sockets. I got a client/server application setup where messages are sent over the wire via TCP. The implementation is done via C++ POCO, however the question is not related to a certain technology.

A message can be a request (initiated by the client) or a response (initiated by the server).

A request has the structure:

Message Header
Request Header
Parameters

A response has the structure

Message Header
Response Header
Parameters

I know TCP guarantees that sent packages will be delivered in the order they have been sent. However, nothing can be assumed about the timespan a delivery might need.

On both sides I have a read/send timeout configured. Now I wonder how to have a clean set up on the transmitted data after a timeout. Don't know how to express this in the right terms, so let me describe an example:

1. Server S sends a response to the client (Message Header, Response Header, Parameters are put into the stream)
2. Client C receives the message header partially (e.g. the first 4 bytes of 12)
3. After these 4 bytes have been received, the reception timeout occurs
4. On client-side, an appropriate exception is thrown, the reception will be stopped.
5. The client considers the package as invalid.

Now the problem is, when the client tries to receive another package, he might receive the lasting part of the "old" response message header. From the point of view of the currently processed transaction (send request/get response), the client receives garbage.

So it seems that after a timeout has occured (no matter whether it has been on client or server-side), the communication should continue with a "clean setup", meaning that none of the communication partners will try to send some old package data and that no old package data is stored within the stream buffer of the respective socket.

So how are such situations commonly handled? Is there some kind of design pattern / idiomatic way to solve this? How are such situations handled within other TCP-based protocols, e.g. HTTP?

In all the TCP samples around the net I've never seen an implementation that deals with those kind of problems...

Thank you in advance

Answer 1

when the client tries to receive another package, he might receive the lasting part of the "old" response message header

He will receive the rest of the failed message, if he receives anything at all. He can't receive anything else, and specifically data that was sent later can't be received before or instead of data that was sent earlier. It is a reliable byte-stream. You can code accordingly.

the communication should continue with a "clean setup", meaning that none of the communication partners will try to send some old package data

You can't control that. If a following message has been written to the TCP socket send buffer, which is all that send() actually does, it will be sent, and there is no way of preventing it short of resetting the connection.

So you either need to code your client to cope with the entire bytestream as it arrives or possibly close the connection on a timeout and start again.