Uploaded image for project: 'OASIS Message Queuing Telemetry Transport (MQTT) TC'
  1. OASIS Message Queuing Telemetry Transport (MQTT) TC
  2. MQTT-572

Clarification of text advising number of inflight messages

    XMLWordPrintable

    Details

    • Type: Task
    • Status: Applied
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: MQTT-SN
    • Labels:
      None
    • Proposal:
      Hide

      Section should read;

      6.6 Client’s Publish Procedure
      After having registered successfully a topic name with the gateway, the client can start publishing data relating to the registered topic name by sending PUBLISH messages to the gateway. The PUBLISH messages contain the assigned topic id.

      All three QoS levels and their corresponding message flows are supported as defined in MQTT. The only difference is the use of topic ids instead of topic names in the PUBLISH messages.
      Regardless of the requested QoS level the client may receive in response to its PUBLISH a PUBACK message which contains either;

      • the ReturnCode= “Rejection: invalid topic Id”: in this case the client needs to register the topic name again before it can publish data related to that topic name; or
      • the ReturnCode= “Rejection: congestion”: in this the client shall stop publishing toward the gateway for at least the time TW AIT .

      At any point in time a client may have only one QoS level 1 or 2 PUBLISH message outstanding in each direction, i.e. it has to wait for the termination of each PUBLISH message exchange before it could start a new level 1 or 2 transaction.

      Show
      Section should read; 6.6 Client’s Publish Procedure After having registered successfully a topic name with the gateway, the client can start publishing data relating to the registered topic name by sending PUBLISH messages to the gateway. The PUBLISH messages contain the assigned topic id. All three QoS levels and their corresponding message flows are supported as defined in MQTT. The only difference is the use of topic ids instead of topic names in the PUBLISH messages. Regardless of the requested QoS level the client may receive in response to its PUBLISH a PUBACK message which contains either; • the ReturnCode= “Rejection: invalid topic Id”: in this case the client needs to register the topic name again before it can publish data related to that topic name; or • the ReturnCode= “Rejection: congestion”: in this the client shall stop publishing toward the gateway for at least the time TW AIT . At any point in time a client may have only one QoS level 1 or 2 PUBLISH message outstanding in each direction, i.e. it has to wait for the termination of each PUBLISH message exchange before it could start a new level 1 or 2 transaction.

      Description

      Presently, the specification section 6.6 Client Publish reads;

      At any point in time a client may have only one QoS level 1 or 2 PUBLISH message outstanding, i.e. it has to wait for the termination of this PUBLISH message exchange before it could start a new level 1 or 2 transaction.

      This is ambiguous and needs to state that the number of message inflight (and indeed message Ids) are PER NETWORK DIRECTION. For example, it is perfectly fine for a device to be sending a message whilst also receiving a message.

        Attachments

          Activity

            People

            • Assignee:
              simon.johnson Simon Johnson [X] (Inactive)
              Reporter:
              simon.johnson Simon Johnson [X] (Inactive)
            • Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: