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-585) CONNACK to contain session present indication


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

Simon Johnson updated MQTT-585:
-------------------------------
    Assignee: Simon Johnson

> CONNACK to contain session present indication
> ---------------------------------------------
>
>                 Key: MQTT-585
>                 URL: https://issues.oasis-open.org/browse/MQTT-585
>             Project: OASIS Message Queuing Telemetry Transport (MQTT) TC
>          Issue Type: Improvement
>          Components: MQTT-SN
>            Reporter: Simon Johnson
>            Assignee: Simon Johnson
>            Priority: Major
>
> Submitted By:ÂPatrick van Bennekom
> Â
> Currently Iâm working on a MQTTSN project (both client and gateway). We have MQTTSN running on an embedded environment making use of a proprietary communication bus with low bandwidth. 
> For this constrained network we try to keep reconnects / and resubscriptions to a minimum by using the cleansession flag.
> Â
> In MQTT we get notified via the status byte of the CONNACK if the broker already has a session stored for our client, this feature is very convenient after a reset of the embedded client or after a restart of the broker and can be used to determine the difference between a communication glitch (a few missing packets) or a new connection (crash/reset of the broker).
> Â
> However, it doesnât seem that MQTTSN has a way of informing us of the sessionPresentflag. This has caused some challenges in our setup where we try to reconnect after a failed publish with cleansession=0 after the broker had reset. The broker informs the MQTTSN-GW of the missing session, but the MQTTSN-GW has no way of providing this information to the client. This left us in a state where we can publish messages, as the GW did remember our topics, but would never receive a subscription because the broker no longer has them stored. 
> Â
> Iâm following the development of MQTTSN V2.0 and to my surprise I saw a new RC code: 0x05 Rejected: no session. Unfortunately, this RC is only used for the disconnect message. Why is this not extended to the connect message to inform the client that no active session was currently found on the broker?
> Â
> Is there another way you plan to incorporate the cleansession/sessionpresent flow in MQTTSN? I think this is a great feature for constrained devices/networks as otherwise we would have to connect cleanly (with all subscriptions) for every communication error.
> Â
> Â
> Â
> ========================
> Â
> The sub-committee agreed this was a good candidate for inclusion in STC call 17/12/2021.
> Â
> Agreed to draft 2 proposals for discussions;
> Â
> 1) 2 new return codes (SUCCESS_SESSION_PRESENT | SUCCESS_SESSION_NOT_PRESENT)
> 2) new field "Session Present".
> Â
> For discussion.



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