6 ms·
> The reliability signals this app needs are built into both TCP and the socket programming interface, from what I can tell. The application-layer acknowledgeme
by oesmith 13y ago
> The reliability signals this app needs are built into both TCP and the socket programming interface, from what I can tell. The application-layer acknowledgement it wants appears duplicative.
An ACK only suggests that a segment has reached the recieve buffer successfully. If the receiving application crashes between buffering incoming data and successfully processing it, that's expressly not TCP's problem. The RST will signal that the receiver has died, but does not imply whether or not the application has successfully processed any buffered data up to that point.
AFAIK, an application-layer acknowledgement is the only way to solve this problem.
- tptacek 13y agoI agree that there are circumstances where you need application-layer acks, SMTP being a canonical example. However, there are other cases where you don't need lock-step app-layer acknowledgements; for instance, if your messages are idempotent. I'm really just reacting to the forensic work in this article, which suggests (maybe I'm misreading) a problem that TCP doesn't actually have.
- oesmith 13y agoYes, if all you want is to confirm that a TCP connection has closed and flushed correctly, then AFAIK, that's entirely possible with a [shutdown, select, read] sequence. I struggle to understand why an RPC system (as detailed in the article) wouldn't want an app-level acknowledgement though...