Community
Participate
Working Groups
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).
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.
AQdded extra timer.
