[OASIS Issue Tracker] (MQTT-320) Expectations of timing accuracy in MQTT implementations

[OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>]

    [ https://issues.oasis-open.org/browse/MQTT-320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=64355#comment-64355 ] 

Andrew Banks commented on MQTT-320:
-----------------------------------

Ed, the worst consequences of inaccurate clocks that you mention seem to be: 
1) A client mail fail to send PINREQ in time. 
    The client could mitigate this by asking for a longer keep alive interval or by accepting that it will have to reconnect. Another possibility would be for the Client to not use Keep alive and rely on a server initiate ping to detect liveness. 
    

2) A server might expire state sooner than it should. 

This would happen if the server clock drifts or is corrected towards the future. The server might know this could happen, for example because it is using a of day clock which is reporting 
a time before some hard coded value which is clearly wrong , like 15 November 2016 (its 17 November at the time of writing) . In this case it could be very lenient with its expiry and perhaps never expire the data. 

> Expectations of timing accuracy in MQTT implementations
> -------------------------------------------------------
>
>                 Key: MQTT-320
>                 URL: https://issues.oasis-open.org/browse/MQTT-320
>             Project: OASIS Message Queuing Telemetry Transport (MQTT) TC
>          Issue Type: Improvement
>          Components: core
>    Affects Versions: 5
>            Reporter: Ian Craggs
>            Priority: Minor
>
> There are a number of aspects of MQTT which involve timings, starting with the keepalive interval, and some new features introduced in MQTT 5 such as message expiration.
> These timers are denoted in seconds (I don't think we have any exceptions to that), but the implementation of those timers in both servers and clients may not actually be at the resolution of small numbers of seconds.  I suggest that we include some wording to limit the expectation of accuracy when a small number of seconds is used on such a timer, where "small" is to be defined, but could be less than 10 for instance.



--
This message was sent by Atlassian JIRA
(v6.2.2#6258)