Improve timeout mechanisms about ruby-mqtt

[balwantk]

@njh what action does one take if at all it has hung?

[njh]

It should send a disconnect packet and then close the TCP socket.

[balwantk]

In the name of fault tolerance, wouldn't it be better to:

• Send a ping, wait 10 seconds for a resp.
• If resp great.
• If no resp, disconnect, and try to reconnect a few times.
• If it works, and we get a resp good.
• Else close the connection and raise like a MQTT::ConnectionError.

Your thoughts?

-Balwant

[Vincent14]

The ping behaviour is bandwidth consumer, such some device should avoid. See this MQTT explanation about Keep Alive mechanism in the protocol spec: https://www.hivemq.com/blog/mqtt-essentials-part-10-alive-client-take-over/

Resume: "If the client does not send a messages during the keep-alive period, it must send a PINGREQ packet to the broker to confirm that it is available and to make sure that the broker is also still available."

[softwaregravy]

coming in 10 years later with a use case ...

We use this on the server, and we are unconcerned with bandwidth. I have observed that we get "stale" connections. I don't know how else to describe it, but we are sitting in the get method, but the mqtt server stops sending us messages. As the control-server, we want to ensure we have an active connection that is just quiet, so being able to ping every X seconds and assume dead if no response would be really valuable.

I agree that you probably wouldn't want bandwidth constrained end-devices to leverage this behavior.