Add controllable support for TCP keepalives

[cverges]

TCP sockets sometimes need keepalives enabled. There doesn't appear to be a way of setting the socket options from the application code to enable such features.

[jadamcrain]

Mmm, issues:

http://stackoverflow.com/questions/20188718/configuring-tcp-keep-alive-with-boostasio
http://stackoverflow.com/questions/292997/can-you-set-so-rcvtimeo-and-so-sndtimeo-socket-options-in-boost-asio

How bad would a 10 byte link status request/reply be every 10 minutes for bandwidth? Have you calculated the overhead? It should be really minimal and would work to timeout any implementation.

[cverges]

I don't think that link layer keepalives are quite the same, and it had to do with third party interop. Not all (most?) other stacks don't implement link layer keepalives, while anyone who implements TCP must hand their keepalives as part of the base standard.

I think inclusion of LL keepalives is good, but we still need TCP keepalive control, too.

[jadamcrain]

It's super easy to add a callback allowing the user to configure the native socket handle, or do it via inheritance. I just don't think adding it to the bindings is a great idea since it isn't portable. Which do you prefer? I believe you have to hand the socket off for configuration after it's been made useful (connected/accepted). This can happen via callback or inheritance.

All stacks we tested in our research (20+) supported the REQUEST_LINK_STATES message (reply with LINK_STATUS). The fuzzer used this as a health check. It's part of the link layer conformance procedures. Not all stack will send them, but they have to reply. This would make the link layer keep alives a much more portable mechanism at the cost of 20 extra bytes (10 request/10 reply) once every (5 min?).

-Adam

[cverges]

If it is easy, then let's do both. Opens up flexibility.

[jadamcrain]

Ok, I'll prototype the native socket callback approach in 2.0.x and then let you test on a real system to see if it works as desired. I'm still worried that if you don't write, you never find out the connection is dead.

[cverges]

We've tested the TCP keepalive using an old GEC stack hack, where we force
keepalive on in the PhysicalLayerAsyncTCP{Client|Server} classes. This
seems to perform the "Dead Peer Detection" as desired, even on a TCP server
socket that is "permanently" in listening state.

[jadamcrain]

Check out this commit:

577e862

Example of usage here:

https://github.com/automatak/dnp3/blob/2.0.x/cpp/masterdemo/DemoMain.cpp#L71

Optional config function gets passed into constructor.

It gets called every time a fresh socket is connected.

[cverges]

Yup, that'll do, I think. Nice use of lambdas.

Chris

On Wed, Nov 27, 2013 at 9:33 PM, Adam Crain notifications@github.comwrote:

Check out this commit:

577e862577e862

Example of usage here:

https://github.com/automatak/dnp3/blob/2.0.x/cpp/masterdemo/DemoMain.cpp#L71

Optional config function gets passed into constructor.

It gets called every time a fresh socket is connected.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/38#issuecomment-29440863
.

[jadamcrain]

Resolved in 2.0.x.