Consider setting TCP_KEEPIDLE time in MLLP.Client

[starbelly]

We have made {:keepalive, true} a default in MLLP.Client. This requires adjusting system wide settings, which is not horrible, but it's also not great either. The default for most operating systems is pretty big and the idle timeout for some MLLP endpoint systems and/or middle boxes in the wild is small (e.g., 10 minutes, 15 minutes, 30 minutes), etc.

An option at our disposal is to set the client to use raw mode ({:packet, :raw}), this would allow us to set raw protocol options on the socket, such as TCP_KEEPIDLE time.

A bit of testing needs to be done and if the results are favorable, then we can provide a few new options to go with {:keepalive, true}. Namely, {:keepidle, N} where N is the amount of time a conn can sit idle before keepalive kicks in. We may also be interested in adding the other counter parts for that (e.g., interval, etc.)

In a nutshell, we have to :

1. Check if keepalive is set to true
2. Check if keepidle was set to a positive integer
3. Check to see if we support the option, that is check the return value of:os.type/0,
4. If it's supported, add the raw options.

Example for Linux and Mac OS :

{:raw, 6, 16, <<time::32-native-integer>>}

Where 6 is the protocol (tcp), 16 is the protocol option (keepidle), and time is the integer value (milliseconds) extracted from the provided option.

Note that normally I wouldn't consider this, but mllp has no probe support to keep a connection alive. It may be fine just to let the connection die and reconnect. However, if low latency is a goal for a user this is pretty essential.

It may be this an option best left up to the user vs putting it in here, but would be a nice to have.

[starbelly]

@josevalim @wojtekmach or @philss from a design PoV what your thoughts?

[josevalim]

I may be missing something, but if a connection has been idle for minutes, how important it is for the latency to be submilliseconds instead of dozens of milliseconds?

[starbelly]

I may be missing something, but if a connection has been idle for minutes, how important it is for the latency to be submilliseconds instead of dozens of milliseconds?

You're not missing anything and you raise a very important question and point within that. On one hand, it should not matter, but it depends I believe.

Some of these systems in the wild can be problematic when connections are severed, thus why we there's a desire to keep the conn alive, and that's more about just that vs low latency itself. In other words, latency would enter the equation when there's a problem disconnecting, re-connecting, failing, backing off, etc.

Does that make sense?

[josevalim]

Alright, this looks good to me then. :) I have nothing more to add and the proposal looks solid.