OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

mqtt message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

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

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

Ken Borgendale commented on MQTT-320:

For batch timeouts you would generally not want to expire something too soon, but for clock skew or administrative action this can certainly happen.  Clock skew is normally pretty small except at very small time intervals.  On the other hand I could see an argument for only checking session expiration every minute which would give a very large accuracy issue for an interval of 1 second.

Administrative configuration or actions is another issue somewhat separate from timer accuracy.  The client might ask us to keep session state for 10 years, but we might only authorize that user to 10 days.  For keepalive we added a return value in CONNACK for this.  For message and session expiration this does not really make sense.  We do have non normative text pointing out that an infinite expiration interval does not really mean we will keep the data forever due to hardware or administrative issues.  We need to have similar language for other timeouts.

> 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

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]