search

eclipse / paho.mqtt.javascript

paho.mqtt.javascript
Other
1.15k stars 467 forks source link

Client disconnecting due to timeout (no pingreq being sent) #46

Closed jpwsutton closed 8 years ago

jpwsutton commented 8 years ago

migrated from Bugzilla #407627 status RESOLVED severity major in component MQTT-JS for --- Reported in version v0.5 on platform All Assigned to: Andrew Banks

On 2013-05-09 03:33:42 -0400, Simon Racliffe wrote:

When the Paho MQTT JS cleint is connected to a server and only subscribes to topics at qos 0 it gets disconnected after the timeout period if it is receiving PUBLISH messages.

In this situation the server sends PUBLISH messages to the client, but with qos 0 the client does not respond with a PUBACK meaning the server does not reset its timeout period.

I think the client is incorrectly resetting its timeout counter when it receives the PUBLISH message, and therefore doesn't send a PINGREQ and hence gets disconnected.

I am using Mosquitto as the server if that is of any relevance (I bleieve not).

On 2013-05-14 09:42:09 -0400, Nicholas O'Leary wrote:

Confirmed - the client incorrectly resets the time-out whenever it sends or receives anything and doesn't distinguish between the two.

This causes two faults with the client:

  1. as reported, if the only messages flowing are qos 0 from the server, the client never sends a PINGREQ so will be disconnected by the server.
  2. if the only messages flowing are qos 0 from the client, the client never sends a PINGREQ so will never detect if the server/network hangs until the TCP connection times out which could be a long time.

Of these two scenarios, # 1 is the more likely and severe. # 2 is an edge case that, whilst not ideal, will at least resolve itself if the TCP connection eventually times out.

A quick fix that addresses # 1, but not # 2, is:

In ClientImpl.prototype._on_socket_message, move the call to reset the pinger from the start of the function to within the case block for MESSAGE_TYPE.PINGRESP. In other words, only reset the ping handling when we receive a pingrep from the broker.

The proper way to handle keepalive logic is to track last-sent and last-received times separately and send a ping when either one exceeds the keepalive time.

On 2013-06-25 04:59:49 -0400, Andrew Banks wrote:

AQdded extra timer.