[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [OASIS Issue Tracker] (MQTT-253) Subscription identification
[ https://issues.oasis-open.org/browse/MQTT-253?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nicholas O'Leary updated MQTT-253: ---------------------------------- Proposal: ## High level description Each subscription is assigned a subscription identifier at the time it is made. Within each session, the subscription identifiers are unique. The subscription identifiers are part of the session state which is preserved across network disconnection for CleanSession=0 sessions. When a client is successfully granted a subscription, the server sends back the subscription identifier in the SUBACK packet. When a message is published whose topic string matches multiple subscriptions in a session, the server is permitted to send the client either one message or one message for each subscription. In the first case, the server should annotate the message sent to the client with the subscription identifiers of all matching subscriptions. In the second case, the server should annotate each message sent to the client with the subscription identifier for the subscription for that copy of the message. The client can use the Subscription Identifier to unsubscribe - or use the Topic Filter as can currently do. Open questions: - Section 3.8.4 says: The Server is permitted to start sending PUBLISH packets matching the Subscription before the Server sends the SUBACK Packet. That means a client may receive a publish with a subscription ID it does not yet know about (because the suback hasn't arrived). Is that a problem? - Does this require a new UNSUBACK return code (invalid sub id), or does 0x11: "No subscription existed" cover it. Spec changes based on wd06: PUBLISH - 3.3.2.7 Matching Subscription List If set, it identifies the Subscriptions that caused this Publish to be sent to the receiver. - M (0x0M) Byte, Identifier of the Matching Subscriptions List. - Variable Byte Integer (N) - the number of matching subscriptions - Followed by N further Variable Byte Integers that identify the matching Subscription Identifiers SUBACK - 3.9.3 Payload Current: The payload contains a list of Return Codes. Each Return code corresponds to a Topic Filter in the SUBSCRIBE Packet being acknowledged. The order of return codes in the SUBACK Packet MUST match the order of Topic Filters in the SUBSCRIBE Packet. Proposed: The payload contains a list of Return Codes (single byte) and Subscription Identifies (Variable Byte Integer) entries. Each entry corresponds to a Topic Filter in the SUBSCRIBE Packet being acknowledged. The order of entries in the SUBACK Packet MUST match the order of Topic Filters in the SUBSCRIBE Packet. If a subscription is accepted, the Subscription Identifier MUST be a non-zero value that is unique to the current Session. If a subscription is not accepted, the Subscription Identified MUST be 0. UNSUBSCRIBE - 3.10.3 Payload Current: The payload for the UNSUBSCRIBE Packet contains the list of Topic Filters that the Client wishes to unsubscribe from. The Topic Filters in an UNSUBSCRIBE packet MUST be UTF-8 encoded strings as defined in Section 1.5.3, packed contiguously. The Payload of an UNSUBSCRIBE packet MUST contain at least one Topic Filter. An UNSUBSCRIBE packet with no payload is a protocol violation. See section 4.8 for information about handling errors. Proposed: The payload for the UNSUBSCRIBE Packet contains the list of Topic Filters or Subscription Identifiers that the Client wishes to unsubscribe from. The Topic Filters are UTF-8 encoded strings as defined in Section 1.5.3. If the length of a Topic Filter string is zero (0) it is followed by a Subscription Identifier encoded as a Variable Byte Integer. The Payload of an UNSUBSCRIBE packet MUST contain at least one Topic Filter or Subscription Identifier. An UNSUBSCRIBE packet with no payload is a protocol violation. See section 4.8 for information about handling errors. was: ## High level description Each subscription is assigned a subscription identifier at the time it is made. Within each session, the subscription identifiers are unique. The subscription identifiers are part of the session state which is preserved across network disconnection for CleanSession=0 sessions. When a client is successfully granted a subscription, the server sends back the subscription identifier in the SUBACK packet. When a message is published whose topic string matches multiple subscriptions in a session, the server is permitted to send the client either one message or one message for each subscription. In the first case, the server should annotate the message sent to the client with the subscription identifiers of all matching subscriptions. In the second case, the server should annotate each message sent to the client with the subscription identifier for the subscription for that copy of the message. The client can use the Subscription Identifier to unsubscribe - or use the Topic Filter as can currently do. Open questions: - Section 3.8.4 says: The Server is permitted to start sending PUBLISH packets matching the Subscription before the Server sends the SUBACK Packet. That means a client may receive a publish with a subscription ID it does not yet know about (because the suback hasn't arrived). Is that a problem? - Does this require a new UNSUBACK return code (invalid sub id), or does 0x11: "No subscription existed" cover it. Spec changes based on wd06: PUBLISH - 3.3.2.7 Matching Subscription List If set, it identifies the Subscriptions that caused this Publish to be sent to the receiver. - M (0x0M) Byte, Identifier of the Matching Subscriptions List. - Variable Byte Integer (N) - the number of matching subscriptions - Followed by N further Variable Byte Integers that identify the matching Subscription Identifiers SUBACK - 3.9.3 Payload Current: The payload contains a list of Return Codes. Each Return code corresponds to a Topic Filter in the SUBSCRIBE Packet being acknowledged. The order of return codes in the SUBACK Packet MUST match the order of Topic Filters in the SUBSCRIBE Packet. Proposed: The payload contains a list of Return Codes (single byte) and Subscription Identifies (Variable Byte Integer) entries. Each entry corresponds to a Topic Filter in the SUBSCRIBE Packet being acknowledged. The order of entries in the SUBACK Packet MUST match the order of Topic Filters in the SUBSCRIBE Packet. If a subscription is accepted, the Subscription Identifier MUST be a non-zero value that is unique to the current Session. If a subscription is not accepted, the Subscription Identified MUST be 0. UNSUBSCRIBE - 3.10.3 Payload Current: The payload for the UNSUBSCRIBE Packet contains the list of Topic Filters that the Client wishes to unsubscribe from. The Topic Filters in an UNSUBSCRIBE packet MUST be UTF-8 encoded strings as defined in Section 1.5.3, packed contiguously. The Payload of an UNSUBSCRIBE packet MUST contain at least one Topic Filter. An UNSUBSCRIBE packet with no payload is a protocol violation. See section 4.8 for information about handling errors. Proposed: The payload for the UNSUBSCRIBE Packet contains the list of Topic Filters or Subscription Identifiers that the Client wishes to unsubscribe from. The Topic Filters are UTF-8 encoded strings as defined in Section 1.5.3. If the length of a Topic Filter string is zero (0) it is followed by a Subscription Identifier encoded as a Variable Byte Integer. The Payload of an UNSUBSCRIBE packet MUST contain at least one Topic Filter or Subscription Identifier. An UNSUBSCRIBE packet with no payload is a protocol violation. See section 4.8 for information about handling errors. > Subscription identification > --------------------------- > > Key: MQTT-253 > URL: https://issues.oasis-open.org/browse/MQTT-253 > Project: OASIS Message Queuing Telemetry Transport (MQTT) TC > Issue Type: New Feature > Components: futures > Affects Versions: 5 > Reporter: Andrew Schofield > Assignee: Nicholas O'Leary > Priority: Minor > Labels: Proposed > > Subscribe and unsubscribe operations are performed on topic filters in MQTT 3.1.1. Adding subscription identifiers would enable unambiguous identification of subscriptions. -- This message was sent by Atlassian JIRA (v6.2.2#6258)
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]