

Using TCP keepalive with Go - r0nin
http://felixge.de/2014/08/26/tcp-keepalive-with-golang.html

======
felixge
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.

------
cnlwsu
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.

~~~
nly
ISPs dropping TCP keep-alives are dicks, violating the end-to-end principle.
Support being "optional" as-per the RFC only refers to the endpoints.

------
Zash
> 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.

