3 ms·
> If the connection breaks while an ACK is outstanding, the sender will have no way of knowing whether the segment was received The real question is, why this
by nirui 2y ago
> If the connection breaks while an ACK is outstanding, the sender will have no way of knowing whether the segment was received
The real question is, why this should be a problem that TCP must solve? TCP gives you a bidirectional waterflow-like pipe, and that's enough for you to create many useful applications. TCP never provided guarantee for correct delivery, that's your job.
For example, if a HTTP request is interrupted before the respond is received, the sender should assume the request never reach the server and try again with a new connection, while the server should mitigate duplicated requests (reject or return a successful code).
Well, maybe that's the point of the article, because many web pages gets confused if you send duplicated requests to them.
- erik_seaberg 2y agoThe server may or may not have seen the request, and the https://en.wikipedia.org/wiki/Two_Generals%27_Problem https://en.wikipedia.org/wiki/Two_Generals%27_Problem proves it impossible to know in every case (no matter how many acks, the last could be dropped). A request that alters state should be retried using the same idempotency key, and the server should try to ack with whether the requested work already happened.