I would like to request some sort of heartbeat, keepalive or a presence poll that wouldn’t count against the commands per minute restriction.
The problem is there is no way for a server to tell it has lost connection to a device until that device refuses a TCP packet (ie, sends a RST packet). Some sort of periodic message would go a long way to helping servers detect and recover from lost connections.
One idea would be to implement a heartbeat command something like
{method:“keepalive”,params[10]} to tell the device to send a small packet every 10 seconds over the open tcp connection. That’s an ‘off the cuff’ idea to illustrate my thinking.
Check this comment in another very old thread, hopefully it will help.
========
For the first issue, it’s about TCP programming paradigm. When your peer socket is closed gracefully, then you can detect it by checking if the return value of “read()” call is 0. When your peer socket is closed abruptly (for example, system power off, even with battery, you can’t guarantee a NOTFIY message will reach to your program), then you have no way to detect it immediately (I think this is the issue that bothers you). The common practice to handle this situation is using SO_KEEPALIVE socket option. After you create the socket, you can call “setsockopt” to enable TCP keep alive mechanism on your socket. TCP_KEEPIDLE, TCP_KEEPCNT, TCP_KEEPINTVL are three other options you need to use. Generally speaking, the logic is: when your TCP/IP stack detect your socket is idle for TCP_KEEPIDLE seconds (no message come from peer), then it will send a packet to peer, if no acknowledge is received, then it will re-send another probe packet at a interval of TCP_KEEPINTVL seconds. Once total retry count reaches TCP_KEEPCNT, TCP/IP stack will assume peer is closed and it will notify your program. You can tune these parameters to make your program react quickly when peer is powered off.