[OASIS Issue Tracker] (MQTT-271) Describing small device limitations, aka "the Arduino problem"

[OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>]

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

Ed Briggs commented on MQTT-271:
--------------------------------

I agree memory constraints are a fundamental problem for small devices.  I would make two points:

1. In addition to specifying the maximum message size the client can accommodate, the server needs to be able to specify the maximum message size it can accommodate.  (256 MB -  (topicsize + headerszie) is the current limit.  So there should be two values exchanged during connection establishment.

2. The problem of what to do if the server needs to send a message larger than the client can accept is a difficult one. The message could have been queued before the destination client has established its connection size.  Since there is no end-to-end error or notification mechanism, the originator of the message is not notified and may continue to generate oversized message.

3. The problem of what a client should do when receiving an oversize message raises a fundamental problem (IMO) in MQTT error handling - there is no distinction between recoverable error (i.e. by re-sending) and non-recoverable errors.  In this case (as in others), the receiving station can either close the link, which can lead to infinite re-transmission and connection cycling, or it can silently ignore the oversize messages, which violates QoS guarantees, and makes troubleshooting difficult.

4. The restriction of the payload size may not solve the memory constraint problem because the sending TCP/IP stack may bundle multiple message into a single TCP/IP segment. From the perspective of MQTT standardization, controlling what Transport does is outside the scope of the specification and we enter into difficulties if we make assumptions about transport behavior that go beyond what the MQTT specification currently requires.

> Describing small device limitations, aka "the Arduino problem"
> --------------------------------------------------------------
>
>                 Key: MQTT-271
>                 URL: https://issues.oasis-open.org/browse/MQTT-271
>             Project: OASIS Message Queuing Telemetry Transport (MQTT) TC
>          Issue Type: Improvement
>          Components: futures
>    Affects Versions: 3.1.1
>         Environment: Very small device implementations.
>            Reporter: Ian Craggs
>
> Small devices, like the original Arduino, may have very limited resource, like 16k of RAM, or less.  For such devices, limiting the storage used by MQTT is very important.  
> They may not even be able to process a message of 30k, for instance, at all.  If it were sent at QoS 1 or 2, it has to be read in before subsequent messages are received.  
> At the moment, it is a server admin task, or application design task, to make sure that messages bigger than a device can handle are not sent to it.



--
This message was sent by Atlassian JIRA
(v6.2.2#6258)