[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]