Improve timeout mechanisms

njh / ruby-mqtt

Pure Ruby gem that implements the MQTT protocol, a lightweight protocol for publish/subscribe messaging.

http://www.rubydoc.info/gems/mqtt

MIT License

541 stars 135 forks source link

Improve timeout mechanisms #17

Open njh opened 12 years ago

njh commented 12 years ago

Detect hung connections.

Check:

a packet has been sent recently
a packet has been received recently

balwantk commented 11 years ago

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

njh commented 11 years ago

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

balwantk commented 11 years ago

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 commented 5 years ago

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 commented 1 year ago

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.