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] (MQTT-299) Metadata: CONNECT and CONNACK Maximum Message Length

    [ https://issues.oasis-open.org/browse/MQTT-299?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=63564#comment-63564 ] 

Ed Briggs commented on MQTT-299:

This proposal introduces a metadata tag which Clients and Servers may use notify each other of limits on the maximum message size they are able to receive.  This capability is useful for Clients which may have limited memory, and for Servers which need to place a upper bound on the aggregate memory consumed by all its Clients.

A Client sends a 'Max Receive Message Size' in the CONNECT if it needs to restrict  the size of message sent to it, and the Server sends a 'Max Receive Message Size" in the CONNACK if it needs to restrict the size of message sent to it. Thereafter, neither sends messages in excess of the others Max Message Size to the other.

If no Max Receive Message Size message is sent, there is no limit on the message size other that those imposed by the MQTT protocol headers and length fields.

The Maximum Message Size lifetime is the transport connection, and it is not stored as session state. This means it is possible to alter value on the next connection, even if message have previously been queued for delivery or retransmission.

If either session partner violates the agreement by sending an oversize message at QoS > 0,
the receive replies with a PUBACK or PUBREC with a 'Message-To-Big' return code. This implicitly acknowledges the transmission so that it will not be re-transmitted, which could otherwise lead to an infinite reconnect-retransmit cycle.  Like other NAKs, this creates a 'gap' in the delivery which was not heretofore possible in the absence of a transport failure.

There are several details requiring further discussion and agreement. I request the guidance of the TC on these topics.

1. What is a message size?  Just payload, or payload + topic, or payload + topic + optional (metadata) tags?    A good case could be made for either of these.  In this proposal, I say the message size is the value of the Remaining Length field.  This is easy to inspect, and a receiver will know very early in the message processing if the message is too big, and can simply discard the next remaining length bytes to discard an oversize message rather than allocating storage for the entire message only to find out it is too big later on.

If we decide that the message size is the payload size only, then we should probably chose a more descriptive name 'Max Payload Size' etc.

2. Should a Server forward a message to a Client it knows the Client can't accept? The Server could either discard the message (and not send it)  or could it send it and rely on  the Client to return a 'nak' as described above.  On the one hand, 'silently discarding' a message is a rude way of handling QoS 1 and QOS 2;  on the other, why incurr the time and cost of transmitting an undeliverable message.

A counterargument might be that if the receiver discards the message, it could increment a counter 'oversized message discarded' that could help to diagnose message loss.

I propose the server should discard the message.

3. How should oversize QoS 0 messages be handled?  There is no NAK to return. One possibility is for the client to silently discard it, in the spirit at most once delivery.  Another would be to use a DISCONNECT with a 'message too large' error code, but this would terminate the transport connection.

I propose an oversize QoS 0 message should simply be dropped.

4. Oversized messages sent by a Client before a CONNACK is received may violate the size limitation. Presumably these may be handled by the foregoing mechanisms, but the Client will not know in advance.

Draft Normative Text

{This section to be added in the CONNACK payload description} 

Max Receive Message Size Advertisement

Identifier value 36 (0x23) followed by 4 byte variable length integer signifies that a Client or Server will reject PUBLISH messages received which are larger than this value.  The message size is defined as the value of the remaining length field.

A Client or Server which does not support the maximum message size of 268,435,455 bytes SHOULD send a CONNECT or CONNACK containing a Max Receive Message Advertisement. Following the reception of a Maximum Receive Message advertisement, Clients and Servers MUST not forward PUBLISH messages to its session partner in excess of this size.

If a Client or Server does not impose a restriction on the Maximum Receive Side, it MUST NOT send a Max Receive Message Size Advertisement.

It is an error to Send a Max Receive Size Advertisement smaller than the size of a minimum MQTT message, containing a QoS 0 message, a 1 byte topic string and zero byte payload.

If a Client or Server receives a message that is larger than previously advertised, it must take the following action:

1. For QoS 0, it SHOULD discard the message and continue processing without disconnecting the transport connection.
2. For QoS 1, it SHOULD discard the message and send a PUBACK with the error code MESSAGE-TOO-BIG. This implicitly acknowledges the message so it will not be redelivered.
3. For QoS 2, it SHOULD discard the message and send a PUBREC with the error code MESSAGE-TO-BIG and continue processing messages. By completing the subsequent PUBREL PUBCOMP processing, the message is implicitly acknowledged and will not be retransmitted.

If a Sever needs to forward a message to a client which is larger than the value of the Max Receive Message Size value contained in the Client's Max Receive Message Size advertisement, it should drop the message regardless of the QoS level.

 The Maximum Receive Message Size value is established on each CONNECTION, and is not stored across transport connections and not part of the session context. If previously queued message or a message waiting for reR

> Metadata: CONNECT and CONNACK Maximum Message Length
> ----------------------------------------------------
>                 Key: MQTT-299
>                 URL: https://issues.oasis-open.org/browse/MQTT-299
>             Project: OASIS Message Queuing Telemetry Transport (MQTT) TC
>          Issue Type: New Feature
>          Components: core
>    Affects Versions: 5
>            Reporter: Brian Raymor
>            Assignee: Ed Briggs
> This was discussed in MQTT-276 (with notes from the F2F meetings) and has been tracked in MQTT-256 (Metadata). 
> I'm opening a separate, specific issue per Ken's comments - https://issues.oasis-open.org/browse/MQTT-256?focusedCommentId=62192&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-62192:
> "All of these would be defined in separate JIRAs, but what we should do in this JIRA is to define the mechanism used to pass these values."

This message was sent by Atlassian JIRA

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