Using TCP keepalive with Go

#1

Post by r0nin » Tue, Aug 26, 2014, 2:07 PM UTC

Re: Using TCP keepalive with Go

#2

Post by cnlwsu » Tue, Aug 26, 2014, 3:24 PM UTC

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.

Re: Using TCP keepalive with Go

#3

Post by nly » Tue, Aug 26, 2014, 4:09 PM UTC

cnlwsu wrote: post #2

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…

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.

Re: Using TCP keepalive with Go

#4

Post by Zash » Tue, Aug 26, 2014, 4:35 PM UTC

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

Re: Using TCP keepalive with Go

#5

Post by felixge » Tue, Aug 26, 2014, 4:44 PM UTC

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.