Detect socket loss in ms - not just link loss

[jpa]

I have a familiar problem, but if there was a direct answer to my specific twist on the forums here, I'm missing it. 

I have two devices that establish a stream connection and pass messages over the socket.  I want some way of knowing when there's any break in the socket communications - preferably within milliseconds, but I can imagine compromising on this if the message load is too great. 

I can detect link loss from the PHY...but that won't help if the break is somewhere between two hubs and not between my device and the hub, since the link to the hub will still be active. 

And it seems as if the RFC specs for TCP sockets put the minimum timeouts in minutes, not seconds, much less milliseconds.

Is there any easier way other than setting up a periodic message and a watchdog timer?  (Or perhaps a reason why even this won't work?) 

John

[Luis_Garabo]

Hi John,

Why don't you open a second socket connection (UDP maybe) which only purpose is to send hearth-bit signal in ms to the other side. If that is lost then you can do whatever in your system to handle it.

Regards,

Garabo

[jpa]

Thanks, Garabo.  I've now done that, although I just use the same socket.  Any special reasons for using a second socket and UDP ?  Is there that much difference in overhead?

[Luis_Garabo]

Hi John,

Well, I think that the second sockets only purpose is to emulate a keep-alive evaluation. If you are using UDP the overhead is smaller, that means all the processing will be faster. Now that I mention it; perhaps the keep alive could be modified and helps you with the first socket. Try changing this socket option:

OPT_KEEPALIVE. By default is not probing the remote endpoint. Change to 1, that should be enough to activate it.

Hope this helps.

Regards,

Garabo

[jpa]

Garabo,

In the MQX documentation, the default value for OPT_KEEPALIVE is listed as "zero minutes", leading me to believe that the unit for this parameter is minutes.  One minute is much too long to wait.  So not much help there.

There's also this thread, which seems to say the same thing.TCP KEEPALIVE Query

Sending a packet every 1/2 second and killing the link if I haven't gotten anything for a full second seems to be working under normal conditions, and 1 second seems tolerable.

John