SO_KEEPALIVE usocket option ?

[mkharibalaji]

Hi Team,
Is SO_KEEPALIVE usocket option available ?

//Hari

[abilio]

@mkharibalaji, not at this moment. Do you specifically need it?

[mkharibalaji]

@abilio Yes ! I have ported pynats NATS.io protocol to work with micropython which would be added to GitHub soon as i am testing it.I need the feature of SO_KEEPALIVE and TCP_NODELAY such that the library is complete or else i can only release with the feature being ported later.

[obertuckerz112]

This should also work right.

[mkharibalaji]

@abilio When can we expect this feature ?

[Wembly]

This feature would be cool to have. In many situations you cannot have a socket opened more than 2 hours without it...
Socket will be dropped without any notification. I have implemented a simple timer that sends a packet every hour as a temporary fix.

[abilio]

@mkharibalaji, KEEPALIVE seems to be supported by the LwIP library that is being internally used by the LoPy/WiPy2, but yet some work is needed in the MicroPython side to take this parameter. Right now we're dealing with completing the support of all important features of the boards, improving free memory, and later we will have a cycle for improvements like this one.

[abilio]

@Wembly, to add my two cents as a sockets user, in the past I tried to use KEEPALIVE for this kind of applications, and fount it to be unreliable (I don't wanna say useless).

For example, the default behavior for all Linux distros I've seen is not to start sending KEEPALIVES until 2 hours of inactivity (that's the shortest recommended interval). Yet, some small devices like home routers will start silently closing connections way before that, so you can easily have more than an hour 45 minutes of quietness without actually realizing the connection was dropped.

The specific reasons not to rely on SO_KEEPALIVE, at least how I read them, are mentioned here: https://tools.ietf.org/html/rfc1122#page-101 (section 4.2.3.6).

This interval MUST be configurable and MUST default to no less than two hours.

If a keep-alive mechanism is implemented it MUST NOT interpret failure to respond to any specific probe as a dead connection.

The TCP specification does not include a keep-alive mechanism because it could: (1) cause perfectly good connections to break during transient Internet failures; (2) consume unnecessary bandwidth ("if no one is using the connection, who cares if it is still good?"); and (3) cost money for an Internet path that charges for packets.

Whenever I've dealt with this situation (knowing if the other end is still there), I implement it pretty much the same way you did. I'm by no means a protocol expert, so if you have important reasons for the need of this feature, I can try push it higher on the list.