Add expiry capabilities to MQTT.

1) Expiry of Session state , add a Session Expiry value in CONNECT. After 3.1.2.10 Keep Alive add: 3.1.2.11 Length of CONNECT Id/Value pairs. The Length of the Identifier/Value pairs in the CONNECT Packet variable header encoded as a Variable Byte Integer. The Length does not include the bytes used to encode the Length. A Length of zero indicates that there are no Identifier/Value pairs in the CONNECT packet. The Id/Value pairs can appear in any order. 3.1.2.12 Session Expiry. Byte 17 (0x11) Identifier of the Session Expiry. Followed by the Four Byte Integer representing the Session Expiry interval in seconds. It is a protocol error to include the Session Expiry interval more than once. The Client and Server can store Session State to enable reliable messaging to continue across a sequence of Network Connections. After a network disconnection and the Session Expiry interval has passed, without a new connection being made the Client and Server each delete the Session State they hold. If the Session State Expiry interval is absent the Session does not expire. If set to zero the Session State is deleted immediately the Network connection is lost. After reconnection the Session lasts as long as the Network Connection plus the new Session Expiry interval. The Session state in the Client consists of: QoS 1 and QoS 2 messages which have been sent to the Server, but have not been completely acknowledged. QoS 2 messages which have been received from the Server, but have not been completely acknowledged. The Session state in the Server consists of: The existence of a Session, even if the rest of the Session state is empty. The Client’s subscriptions. QoS 1 and QoS 2 messages which have been sent to the Client, but have not been completely acknowledged. QoS 1 and QoS 2 messages pending transmission to the Client. QoS 2 messages which have been received from the Client, but have not been completely acknowledged. Optionally, QoS 0 messages pending transmission to the Client. If the session is currently disconnected, the time at which the Session State will be deleted. A will message, if present in CONNECT. Retained messages do not form part of the Session state in the Server, they MUST NOT be deleted when the Session ends [MQTT-3.1.2.7] . See Section 4.1 for details and limitations of stored state. When the Session State expires the Client and Server need not process the deletion of state atomically. On receipt of any other Identifier or Value, the receiver MUST close the network connection. Non normative comment Typically, a Client will always connect using the same Session Expiry interval. The choice will depend on the application. A Client using Session Expiry set to 0 will not receive old Application Messages and has to subscribe afresh to any topics that it is interested in, each time it connects. A Client using a non zero Session Expiry will receive all QoS 1 or QoS 2 messages that were published while it was disconnected. Hence, to ensure that you do not loose messages while disconnected, use QoS 1 or QoS 2 with no Session Expiry or a Session Expiry greater than zero. Non normative comment When a Client connects with long Session Expiry, it is requesting that the Server maintain its MQTT session state after it disconnects for an extended period. Clients should only connect with a long Session Expiry, if they intend to re connect to the Server at some later point in time. When a Client has determined that it has no further use for the session it should disconnect with Session Expiry 0. Non normative comment A Client might be connecting to a server using a network that provides intermittent connectivity. This Client can use a short Session Expiry so that it can re connect when the network is available again and continue reliable message delivery. If the client does not re connect, allowing the Session State to expire, then application messages may be lost. Non normative comment If the client connects using this protocol, then re connects using the MQTT V3.1.1 protocol using cleanSession=0 before the session has expired, then the session state is kept indefinitely. Non normative comment The Client can avoid implementing its own session expiry and instead rely on the Session Present returned from the server to determine if the Session had expired. If the Client does implement its own Session Expiry it needs to store the time at which the Session State will be deleted as part of its session state. Non normative comment The Client and Server clocks might drift and not measure time intervals accurately. The Client should always rely on the Session Present flag in the CONNACK packet rather than try to calculate whether the Server actually did keep its Session State. Update section 3.1.2.11 Variable header non normative example to show no Clean Session flag and add Optional CONNECT values with a Session Expiry interval. In CONNACK Replace 3.2.2.2 Session Present Position: bit 0 of the Connect Acknowledge Flags. If the Server accepts a connection with Session Expiry set to 0, the Server MUST set Session Present to 0 in the CONNACK packet in addition to setting a zero return code in the CONNACK packet [MQTT-3.2.2-1] . If the Server accepts a connection with non zero Session Expiry, the value set in Session Present depends on whether the Server has stored Session state for the supplied client ID. If the Server has stored Session state, it MUST set Session Present to 1 in the CONNACK packet [MQTT-3.2.2-2] . If the Server does not have stored Session state, it MUST set Session Present to 0 in the CONNACK packet. This is in addition to setting a zero return code in the CONNACK packet [MQTT-3.2.2-3] . The Session Present flag enables a Client to establish whether the Client and Server have a consistent view about whether there is already stored Session state. Once the initial setup of a Session is complete, a Client with stored Session state will expect the Server to maintain its stored Session state. In the event that the value of Session Present received by the Client from the Server is not as expected, the Client can choose whether to proceed with the Session or to disconnect. The Client can discard the Session state on both Client and Server by disconnecting, with a Session Expiry set to 0. If a server sends a CONNACK packet containing a non-zero return code it MUST set Session Present to 0 [MQTT-3.2.2-4] . The Server retains knowledge of the Session for the duration of Session Expiry, even if the Session Contains no Messages or Subscriptions. The Session Present flag in the CONNACK Packet indicates if the Session State was actually present when a new connection is made. Non normative comment The clock in the Client or Server may not be running for part of the time interval, for instance because the Client or server are not running. This might cause the deletion of the state to be delayed. 2) The DISCONNECT packet has an optional Session State Expiry Interval, if present this overrides the value set on CONNECT. Replace 3.14.2 DISCONNECT Variable header: 3.14.2.1 The Length of the Identifier/Value pairs in the DISCONNECT Packet variable header encoded as a Variable Byte Integer. The Length does not include the bytes used to encode the Length. A Length of zero indicates that there are no Identifier/Value pairs in the DISCONNECT packet. The Id/Value pairs can appear in any order. 3.14.2.3 Session State Expiry interval. Byte 17 (0x11) Identifier of the Session Expiry interval. Followed by the Four Byte Integer representing the Session Expiry interval in seconds. It is a protocol error to include the Session Expiry more than once. If the Session State Expiry interval is absent the Session Expiry in the CONNECT packet is used. If the Session Expiry in the CONNECT packet was zero it is a protocol error to set a non zero Session Expiry in the DISCONNECT packet. Note that this Jira does not change the conditions governing the publication of a Will message. Jira 290 discusses the posibility of sending a Will message when Session expiry occurs. 3) Update the description of the PUBLISH Packet to include the Publication Expiry interval. After x.x.x.x Payload Format Indicator. add: x.x.x.x Publication Expiry interval. Byte 2 (0x02) Identifier of the Publication Expiry interval. Followed by the Four Byte Integer value of the Publication Expiry interval. If absent, the publication does not expire. If present the four byte value is the lifetime of the publication in seconds. The server MUST attempt start delivery to a matching subscriber until at least this number of seconds has passed, or the session state is deleted. The PUBLISH packet sent to a client by the server MUST contain a Publication Expiry interval set to the received value minus the time that the publication has been waiting in the server. See Section 4.1 for details and limitations of stored state. The Server MAY avoid implementing publication expiry by passing the Publication Expiry interval unchanged to any matching subscribers. In section 4.3.3 QoS 2: Exactly once delivery, for the Sender add: MUST NOT apply Publication Expiry if a Publish Packet has been sent. In section 4.3.3 QoS 2: Exactly once delivery, for the Receiver add: MUST NOT apply Publication Expiry until after PUBCOMP has been sent.