[OASIS Issue Tracker] (MQTT-272) Recommend adding time to live to requests.

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

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

Ken Borgendale commented on MQTT-272:
-------------------------------------

Time to live, expiration, or expiry (depending on your language) can be very useful in freeing up the use of unnecessary resources.  However, there are a number of significant problems.  The general response to these problems is to state in the architecture that message expiration is not guaranteed but done as best effort.  

Requestors who need to reuse a correlation ID need more logic than to rely on message expiration.  Clients cannot depend that an expired message is not delivered as the MQTT spec does not define where the various queuing between client and server is done.

The biggest problem is that there is no reason to believe that the various clients and servers involved share a common clock source.  A server which is a cluster may not itself have a common clock source (although one would hope they are synchronized to some extent).  Without a common clock source, it is not possible to even determine the elapsed time.  For instance, how long has it been since the message was published.  At what point in the process does the TTL start and end?   If your time tolerances are large enough then this is less of an issue.  

Another problem is that in MQTT both the server and client keep state, so for high QoS messages this state can become unsynchronized when a message is expired.

If the purpose of message expiration is to free up resources and we are pretty tolerant of time differences then we can define it well enough,  We should do that first and then see how it applies in various cases such as request / response.



> Recommend adding time to live to requests.
> ------------------------------------------
>
>                 Key: MQTT-272
>                 URL: https://issues.oasis-open.org/browse/MQTT-272
>             Project: OASIS Message Queuing Telemetry Transport (MQTT) TC
>          Issue Type: Improvement
>          Components: futures
>            Reporter: Andrew Banks
>
> The requester will want to limit the number of outstanding requests,  because it has to correlate the responses and because it wants to keep the correlator ids short and small in number.
> To help with this it is useful if the requestor can abandon an incomplete request and reuse the correlator for a new request.



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