[OASIS Issue Tracker] (MQTT-252) Support for large message transmission

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

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

Raphael Cohen commented on MQTT-252:
------------------------------------

In principle, I'm supportive, but this has the potential to be a can of worms. In AMQP, we got this, very, very wrong, using partial acknowledgments, and made an implementer's (and application user's) life hell.

It is worth considering that an alternative architectural pattern to large message transfer is to send a command message with a 'pointer' to an URL where the message can be retrieved using HTTP (with partial ranges, so supporting reconnection). The downside to this approach is that a number of commercial 2G (GRPS) chipsets* only support one TCP connection at a time, so necessitating complex connect / disconnect logic.

*This is a very real issue for one large India-based vendor of IoT solutions using MQTT.

> Support for large message transmission
> --------------------------------------
>
>                 Key: MQTT-252
>                 URL: https://issues.oasis-open.org/browse/MQTT-252
>             Project: OASIS Message Queuing Telemetry Transport (MQTT) TC
>          Issue Type: New Feature
>          Components: futures
>    Affects Versions: 3.1.1
>            Reporter: Andrew Schofield
>
> MQTT has an architected limit of 256MB for the message payload. In practice, transmitting a message this large is troublesome. First, the transmission of large messages ties up the network connection for a considerable time, potentially blocking smaller messages. Second, the longer a message takes to transmit, the higher the chance that a network outage will interrupt the transmission, which would then have to be restarted from the beginning. MQTT would make a good transport for delivery of large payloads, in particular device firmware, but only if they can be transmitted in a more manageable way.



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