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-553) Clarify whether clients should maintain normal topicIds during sleep state


     [ https://issues.oasis-open.org/browse/MQTT-553?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ian Craggs updated MQTT-553:
----------------------------
    Proposal: 
Section 6.14 Support of Sleeping Clients

{color:#de350b}Add this paragraph, which closely follows MQTT 5.0. {color}

Â

Topic Alias mappings exist only within a Network Connection and last only for the lifetime of that Network Connection.

Topic Alias mappings exist only while a client isÂ_active_. A receiver MUST NOT carry forward any Topic Alias mappings from oneÂ_active_Âstate to another.

  was:
Section 6.14 Support of Sleeping Clients

{color:#de350b}Add this paragraph, which closely follows MQTT 5.0. {color}

Topic Alias mappings exist only while a client isÂ_active_. A receiver MUST NOT carry forward any Topic Alias mappings from oneÂ_active_Âstate to another.


> Clarify whether clients should maintain normal topicIds during sleep state
> --------------------------------------------------------------------------
>
>                 Key: MQTT-553
>                 URL: https://issues.oasis-open.org/browse/MQTT-553
>             Project: OASIS Message Queuing Telemetry Transport (MQTT) TC
>          Issue Type: Improvement
>          Components: MQTT-SN
>    Affects Versions: MQTT-SN-1.2
>            Reporter: Simon Johnson
>            Assignee: Ian Craggs
>            Priority: Minor
>              Labels: Implementation-notes
>
> Whether or not a client maintains its normal topicId registry whilst in a sleeping state is a fundamental implementation decision, and one that effects the entire client lifecycle and broker interactions upon waking. I do not believe this to be a trivial implementation detail or broker "feature".
> Should, for example, the broker have to re-issue REGISTER messages for every unconfirmed topic during a wake up phase, only for them to be cleared again upon receipt of the PINGRESP.
> Mandating clients maintain the registry across sleeps, means low powered devices can not truly power down where they have only volatile space to write their registry's. Flushing the registry means more message interaction upon wake. 
> Neither are small overheads. Perhaps there is scope for different sleep states?



--
This message was sent by Atlassian Jira
(v8.3.3#803004)


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