Two general agreement and TCP handshake

Question

So the two general problem states that there is no deterministic way of knowing if the other party - to whom we communicate via a unreliable channel - has received our messages. This is quite analogous to the TCP handshake where we send a syn syn ack ack and establish a connection. Isn't this opposing the two general problem claim?

Answer 1

The two general problem is indeed the asynchronous model for TCP, which is why (as the theoretical result shows) the two endpoints cannot simultaneously have common knowledge about the state of the connection.

The way every distributed agreement protocol deals with this issue is to always promise safety (nothing bad will happen), but cannot guarantee liveness (that progress will eventually be made). Liveness is not in your hands. In good times, one can try to do ones best and hope to make progress.

In TCP it means that an endpoint can make an assumption (such as "connection established") without definitely knowing the other's state. However, it is not an unsafe assumption to make; at worst, it is a benign misunderstanding. After a timeout, it will change its opinion. It is no different from being on one end of a long-distance telephone and continuing to talk thinking the connection is still on; after a while, you may have to ask "hello, you still there?", and time out. Real world protocols must always have timeouts (unlike asynchronous formal models) because somewhere up the stack they serve some human function, and human patience is limited. In practice, there are sufficiently good stretches of time that progress can be made, so we just have to pick appropriate timeouts that don't time out too early either.

That said, even benign misunderstandings can have undesirable consequences. For example, after a server responds to the syn, it allocates resources for the connection in the hope that the client will finish the protocol. This is a classic denial of service attack because a rogue client can simply start off the handshake sequence but never finish it, leaving an unprepared server with millions of state machines allocated. Care is required.