Article points it out but to put a little emphasis on it. Its a good idea to implement a software level keep alive instead of relying on the TCP level one. Some ISPs drop keepalives, especially cellular carriers (support is optional and not guaranteed per rfc). Keeping a persistent connection over some of these networks are tricky and require different minimum timeouts... and some charge by amount of data so you want to keep it as minimal as possible in IoT land.
> What will happen to my connection if the network cable is unplugged?
What will happen to your connection if the network cable is plugged back in? Guess what, TCP will most likely recover and behave as if nothing happened. Keep in mind that opening a new connection is probably pretty expensive, especially if TLS is involved. So keep calm and let TCP do its magic.
Author here. I'd like to clarify that my use case involves talking to devices inside a factory (i.e. LAN) that are expected to be physically connected/disconnected on occasion. The devices are speaking a text protocol, and my goal was to expose a console UI for occasional manual debugging of those devices. I consider it to be good UX to detect network issues persisting for more than a certain duration, but unfortunately the text protocol does not support heartbeats. So given those constraints, TCP keepalive seemed appropriate, especially since dropping a connection a little to eagerly is not an issue here.
Edit: I'm saying this to clarify that I'm not recommending TCP keepalive for most scenarios.
4 comments
[ 3.1 ms ] story [ 17.6 ms ] threadWhat will happen to your connection if the network cable is plugged back in? Guess what, TCP will most likely recover and behave as if nothing happened. Keep in mind that opening a new connection is probably pretty expensive, especially if TLS is involved. So keep calm and let TCP do its magic.
Edit: I'm saying this to clarify that I'm not recommending TCP keepalive for most scenarios.