[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [OASIS Issue Tracker] (MQTT-271) Describing small device limitations, aka "the Arduino problem"
[ https://issues.oasis-open.org/browse/MQTT-271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=60727#comment-60727 ]
Ken Borgendale commented on MQTT-271:
-------------------------------------
The problem we have found with very small devices is that they require a maximum size of the IP packet which they receive, a maximum size of the TLS record, and a maximum size of the MQTT request packet. Some also want to guarantee that the IP, TLS, and MQTT packets are always aligned on a 1 to 1 basis. We also had a requirement to limit the flow rate of QoS=0 messages to a device.
Some of these make sense to specify within MQTT, but much of this is controlled at other levels in the network stack.
So if MQTT defines a set of constraints, can the actual requirements of a highly constrained client be fully specified within MQTT? Do we derive that if the client asks for a 512 byte max payload they want 1 to 1 MQTT to IP packets?
Would it make more sense to pass something like a piece of metadata on the connect to indicate a client constraint which could then be configured on the server? This seems like a case of CONNECT metadata, but you could argue the same for userid and password.
> 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)
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]