[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=64179#comment-64179 ] 

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

Below are paraphrased versions of what we currently have by way of timers 
in the specification and some notes on each one. 

There is no need for any mention 
of absolute time of day or the accuracy with which the time of day is set 
because all of the timers use time intervals. 

The use of "minimum" intervals and "after" mean that implementations are 
permitted to make allowances for the measurement accuracy of these intervals.
For example if there is doubt that a time interval has passed, then the 
implementation is allowed to wait longer, until it is certain.

Keep Alive 
----------

The MINIMUM time interval in seconds before the client is presumed dead if no
packets are received by the server.

The server MUST disconnect the client AFTER 1.5 times the keep alive interval.

PINGRESP  should be sent PROMPTLY by the server, its arrival at the client is
advisory and its up to the client to decide what to do if it does not arrive.


Note: The "1.5 times" came about to make it clear which end should add a fudge factor
and how much. We wanted to avoid situations where both ends had made 
different assumptions.

Note: This is a case where the client should adopt early processing to send the PINGREQ
      rather than late processing.

Note: Clock drift can be important here because both ends are measuring the time
      interval. The "1.5 times" means this is unlikely to be an issue in practice.   


Session Expiry
--------------

The MINIMUM time interval in seconds after network disconnection before the 
client and server can delete the session state.

Note: Clock drift and clock accuracy could be important here. The specification 
      advises the client to use the Session Present flag, not the time calculation to 
      determine if the server still has session state. 
 


Will Delay
----------

The MINIMUM time interval in seconds which the server must wait before publishing
the will message.


Publication Expiry Interval
---------------------------

The MINIMUM time interval in seconds during which the Server should try to 
deliver a message. AFTER this time the Server will destroy the message.

The publish packet sent to the client contains the remaining expiry interval
as calculated by the server.

Note: An implementation might decide to store the time of day when delivery 
      was first attempted. So long as it uses the same clock to calculate the
      remaining time clock skew is unimportant.

Note: The message received by the client might contain an over estimate of the
      the message lifetime but never an under estimate.




> 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)