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] Commented: (MQTT-31) Clarification of 2.2.1 (Message Identifiers)


    [ http://tools.oasis-open.org/issues/browse/MQTT-31?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=34116#action_34116 ] 

Rahul Gupta commented on MQTT-31:
---------------------------------

Updated in WD-07 with Packet Identifier details
----------------------------------------------------------------

The variable header component of many of the Control Packet types includes a 2 byte Packet Identifier (PacketId) field. These Control Packets are PUBLISH (where QoS >0), PUBACK, PUBREC, PUBREL, PUBCOMP, SUBSCRIBE, SUBACK, UNSUBSCRIBE, UNSUBSCRIBE, UNSUBACK.

A PUBACK, PUBREC, PUBREL control packet MUST contain the same PacketId as the PUBLISH control packet that initiated the flow. Similarly SUBACK and UNSUBACK MUST contain the PacketId that was used in the corresponding SUBSCRIBE or UNSUBSCRIBE control packet.

A PUBLISH control packet MUST NOT contain a PacketId if its QoS value is set to 0.

SUBSCRIBE, UNSUBSCRIBE, and PUBLISH (in cases where QoS > 0) MUST contain a non-zero 16-bit value PacketId. Each time a client sends a new packet of one of these types it MUST assign it a distinct PacketId. If a client resends a particular control packet, then it MUST use the same PacketId in subsequent resends of that packet. The client MUST NOT reuse a PacketId value until it has processed an acknowledgement packet (PUBREC in the case of QoS 2) that contains that PacketId. The same conditions apply to a server when it sends a PUBLISH with QoS > 0.

Non-Normative comment

The client and server assign PacketId independently of each other. It is possible for a client to send a PUBLISH control packet with PacketId 0x0001 and then receive a different PUBLISH with PacketId 0x0001 from its server before it receives a PUBACK for the PUBLISH that it sent. 

> Clarification of 2.2.1 (Message Identifiers)
> --------------------------------------------
>
>                 Key: MQTT-31
>                 URL: http://tools.oasis-open.org/issues/browse/MQTT-31
>             Project: OASIS Message Queuing Telemetry Transport (MQTT) TC
>          Issue Type: Improvement
>          Components: edits
>            Reporter: Peter Niblett
>            Assignee: Rahul Gupta
>            Priority: Minor
>
> I found the discussion of the presence/absence of MessageIds, and the presence of a MessageId of 0 to be rather confusing.  My understanding is that a MessageId of 0x0000 is never sent (in QoS=0 Publish the MessageId is omitted entirely). The 3.1 spec seemed clear on this point, yet line 432 of WD04 says "A message identifier of zero MUST be present in a PUBLISH where Qos = 0".
> Also there is no definition of "complete" as used in line 438. Finally as this is an opaque field, there's no need to describe it as an integer, and thus the table showing it as MSB / LSB in line 464 is redundant.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://tools.oasis-open.org/issues/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


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