[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [OASIS Issue Tracker] (MQTT-554) Should QoS 0 messages be held on a message queue during sleep cycle
[ 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. For each message the gateway sends to the client, the messages' quality of service shall be honoured and a full message interaction shall take place, including any associated retransmission logic.* 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:
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. For each message the gateway sends to the client, the messages' quality of service shall be honoured and a full message interaction shall take place, including any associated retransmission logic.* 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.
> 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)
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]