After reading this post about the inherent problems of TCP connection termination, I almost feel sorry for the protocol. It seems to be trying so hard, but doomed for inevitable failure.
Martin Sustrik goes through all the reasons this is problematic in great detail. His main takeaway is that the symmetrical nature of TCP termination call can’t be consistently reliable. Really well thought out, plus the diagrams really help visualize a lot of the problems.
Martin Sustrik comments:
The shortcomings of TCP connection termination have been described many times. If you are not familiar with those problems here’s an example of an article that focuses on the problem.
However, there’s one special use case that is rarely, if ever, discussed.
Imagine a TCP client wanting to shut down its TCP connection to server cleanly. It wants to send the last request to the server, read any responses it may produce and exit.
Given that it has no idea how many responses are about to arrive it can’t just close the socket (it would miss the responses) but, at the same time, it cannot just go on reading responses forever (that would make it hang after the last response is received). What it needs is some way to let server know that it is shutting down. The server should then send back all the pending responses and subsequently acknowledge the shut down.
Read more at: Why is my TCP not reliable (expert edition)
- GDPR, Enrico Signoretti, and Licensing in Gestalt News 18.4 - January 22, 2018
- Smartphones, Cars, and Democracy - January 18, 2018
- Enrico Signoretti – IT Origins - January 18, 2018
- Seeing the Impacts of Spectre on AWS - January 17, 2018
- Gestalt IT Rundown – January 17, 2018 - January 17, 2018
- BetterTouchTool and the Redemption of the Touch Bar - January 17, 2018
- Licensing Models Matter- The On-Premise IT Roundtable - January 16, 2018
- 400G Ethernet, Gina Minks, and WPA3 in Gestalt News 18.3 - January 15, 2018
- Accenting AI - January 12, 2018
- Mattermost: Your Own Private Slack - January 12, 2018