4 ms·
> after you've sent data and received no application-layer acknowledgement This would be the most robust fix. Have the server return "OK" or something after it
by BetaCygni 13y ago
> after you've sent data and received no application-layer acknowledgement
This would be the most robust fix. Have the server return "OK" or something after it has processed the data. It could have silently crashed but still accept connections.
- tptacek 13y agoI'm not sure I see how this is more robust than simply checking to make sure you had an orderly close. The orderly close check should also catch the case where the application crashes after its TCP stack has received the data but before the application processed it. I'm not saying there's never any point to application acknowledgements; look at any careful SMTP server implementation for a study of how to handle these problems. TCP can promise a reliable transport but obviously not a reliable disk.
- noselasd 13y agoThough, the contract you have with TCP , is between TCP at your end and the TCP at the peer, not that it also have delivered the data to the application of the peer. If the peer crashes just as it read() the data, but didn't process it, it will look just as a normal clean close on the sender machine if there arn't more data laying around in the TCP buffers.
- tptacek 13y agoTo be clear, you're talking about the case where the application dequeues the data from its receive queue and then crashes. If you close a socket without reading queued data, you get an RST.