Clarification of keep alive responsibility of client, esp. when using QOS0?

[Andrew Pullin]

Hi folks,

I had a technical question about the MQTT spec.
The scenario where my quandary arises is where a device is making periodic QOS0 publishes to the broker, but never QOS1 or 2, and the device rarely receives any subscription content.
Given that device setup, along comes a failure wherein a half-open or "zombie" TCP socket believes that it is still successfully sending bytes.
In this scenario, what is the correct action of the keep alive mechanism?

According to [MQTT-3.1.2-23]:
"It is the responsibility of the Client to ensure that the interval between Control Packets being sent does not exceed the Keep Alive value. In the absence of sending any other Control Packets, the Client MUST send a PINGREQ Packet."

As far as I can tell, and which appears to be in the PAHO MQTT implementation too, as long as the TCP socket reports that the intended number of bytes were written (irrespective of the actual physical success of that transmission), the internal timer that is used to respect this requirement gets reset. This seems to meet the spec given that a PUBLISH is listed as a "control packet".
Since it is QOS0, no PUBACK is expected or given from the broker.
So the device can continue along with regular zombie-publishing, resetting it's requirement timer each time, and never considering that it MUST send a PINGREQ.

So, what am I missing here? Unless I've misread something, this seems to be a failure case that is not covered by the spec.

Reconciliations that come to mind would be:
- Don't count a QOS0 publish as satisfactory to reset the requirement of [MQTT-3.1.2-23]
OR
- Redefine the keep-alive interval to have no requirements on it, that the device is agreeing to send a PINGREQ on this interval no matter what, as part of the promise of it's connection request.

Any input is definitely welcome. I hope I haven't missed something obvious.

Thanks,
Andrew Pullin

[Roger Light]

Hi Andrew,

I take the view that I want to catch the half open connection case, so
in the scenario that you describe of just publishing qos 0 packets, I
would have the client periodically send a PINGREQ to ensure that it
knows that the connection is still operating correctly.

Cheers,

Roger

> --
> To learn more about MQTT please visit http://mqtt.org
> ---
> You received this message because you are subscribed to the Google Groups
> "MQTT" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to mqtt+uns...@googlegroups.com.
> To post to this group, send email to mq...@googlegroups.com.
> Visit this group at https://groups.google.com/group/mqtt.
> For more options, visit https://groups.google.com/d/optout.