[OASIS Issue Tracker] (MQTT-554) Should QoS 0 messages be held on a message queue during sleep cycle

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

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

Simon Johnson updated MQTT-554:
-------------------------------
    Proposal: 
Section should read;

6.14 Support of sleeping clients
Sleeping clients are clients residing on (battery-operated) devices that want to save as much energy as possible. These devices need to enter a sleep mode whenever they are not active, and will wake up whenever they have data to send or to receive. The server/gateway needs to be aware of the sleeping state of these clients and will buffer messages destined to them for later delivery when they wake up. *The gateway may choose to buffer messages of all quality of service levels (including QoS 0) whilst the client is sleeping and within the expiry interval.*

-- SLEEPING CLIENT STATE DIAGRAM --

Figure 4: Clientâs state transition diagram

As illustrated in Fig 4, from the perspective of the server/gateway, a client may be in one of the following states: active, asleep, awake, disconnected, or lost. A client is in the active state when the server/gateway receives a CONNECT message from that client, as described in section 6.2. This state is supervised by the server/gateway with the âkeep aliveâ timer as described in section 6.11. If the server/gateway does not receive any message from the client for a period longer than the keep alive duration (indicated in the CONNECT message), the gateway will consider that client as lost and activates for example the Will feature for that client.
A client goes to the disconnected state when the server/gateway receives a DISCONNECT without a duration field. This state is not time-supervised by the server/gateway.


If a client want to sleep, it sends a DISCONNECT message which contains a sleep duration. The server/gateway acknowledges that message with a DISCONNECT message and considers the client for being in asleep state, see also Fig. 5. The asleep state is supervised by the server/gateway with the indicated sleep duration. If the server/gateway does not receive any message from the client for a period longer than the sleep duration, the server/gateway will consider that client as lost and - as with the keep alive procedure - activates for example
the Will feature. During the asleep state, all messages that need to be sent to the client are buffered at the server/gateway.

-- SLEEPING CLIENT SEQUENCE DIAGRAM --

Figure 5: Sleep procedure
The sleep timer is stopped when the server/gateway receives a PINGREQ from the client. Like the CONNECT message, this PINGREQ message contains the Client Id. The identified client is then in the awake state. If the server/gateway has buffered messages for the client, it will sends these messages to the client. The transfer of messages to the client is closed by the server/gateway by means of a PINGRESP message, i.e. the server/gateway will consider the client as asleep and restart the sleep timer again after having sent the PINGRESP message.
If the server/gateway does not have any messages buffered for the client, it answers immediately with a PINGRESP message, returns the client back to the asleep state, and restarts the sleep timer for that client.
After having sent the PINGREQ to the server/gateway, the client uses the âretransmission procedureâ of section 6.13 to supervise the arrival of messages sent by the server/gateway, i.e. it restarts timer Tretry when it receives a message other than a PINGRESP, and stops it when it receives a PINGRESP. The PINGREQ message is retransmitted and timer Tretry restarted when timer Tretry times out. To avoid a flattening of its battery due to excessive retransmission of the PINGREQ message (e.g. if it looses the gateway), the client should limit the retransmission of the PINGREQ message (e.g. by a retry counter) and go back to sleep when the limit is reached and it still does not receive a PINGRESP message.

From the asleep or awake state a client can return either to the active state by sending a CONNECT message or to the disconnected state by sending a normal DISCONNECT message (i.e. without a session expiry interval field). The client can also modify its sleep duration by sending a DISCONNECT message with a new value of the sleep session expiry interval.
Note that a sleeping client should go the awake state only if it just wants to check whether the server/gateway has any messages buffered for it and returns as soon as possible to the asleep state without sending any messages to the server/gateway. Otherwise, it should return to the active state by sending a CONNECT message to the server/gateway.

  was:
*6.14 Support of sleeping clients* should be amended to read;

Sleeping clients are clients residing on (battery-operated) devices that want to save as much energy as possible. These devices need to enter a sleep mode whenever they are not active, and will wake up whenever they have data to send or to receive. The server/gateway needs to be aware of the sleeping state of these clients and will buffer messages destined to them for later delivery when they wake up. *The gateway may choose to buffer messages of all quality of service levels whilst the client is sleeping.*


> Should QoS 0 messages be held on a message queue during sleep cycle
> -------------------------------------------------------------------
>
>                 Key: MQTT-554
>                 URL: https://issues.oasis-open.org/browse/MQTT-554
>             Project: OASIS Message Queuing Telemetry Transport (MQTT) TC
>          Issue Type: Improvement
>          Components: MQTT-SN
>    Affects Versions: MQTT-SN-1.2
>            Reporter: Simon Johnson
>            Assignee: Simon Johnson
>            Priority: Minor
>              Labels: Implementation-notes
>
> Clarification as to whether QoS 0 messages are held on a sleeping client's message queue.



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