Ping timeout when connection is functional but busy

Mosquitto MQTT Broker
1

I have a client written using the Mosquitto client library that emits a large number of messages very quickly. The broker cannot keep up, so the outgoing message queue in the client becomes large. This happens, for example, during initial connection when all the retained messages are queued at once. When that happens, the keepalive messages join the end of the queue and are delivered quite late, causing the connection to be dropped due to a keepalive timeout. There is plenty of traffic on the connection, and there is no actual reason to declare a timeout.

Can the algorithm that determines a timeout be modified to (optionally?) treat any incoming data as evidence of a valid connection instead of relying exclusively on the ping/pong messages? I guess this would violate the spec, but it would be a valuable deviation that could be off by default.

2

Hello,

Any complete MQTT packets that are received by the client reset the keepalive timeout already, so this should be happening already - in fact it shouldn’t even be sending a PINGREQ message.

The ping mechanism applies in both directions - you are sending many PUBLISH messages, but is there definitely traffic coming back from the broker? Like a PUBACK?

Regards,

Roger

3

Thanks for responding. I was just in the process of deleting the post. I was wrong about the facts of my question. Wireshark tells me that the broker’s TCP window is full and communication has in fact halted. I went back to the spec and confirmed what you said in your response. I just completely misinterpreted what I was seeing.