Talk:MQTT

Commercial vs. Open source

The table lists "Open source" as alternative to "Commercial". This is not the case: neither in principle, as open source software must be commercially usable to be defined as such, nor in practice, as open source software is routinely used for commercial purposes and there are lots of companies which thrive on open source software.

The correct opposition is between "open source" (or "free") software vs. "proprietary" software. In order to correct the problem, I have changed all occurrences of "Commercial" with "Proprietary" in the table. --Pot (talk) 16:17, 22 July 2013 (UTC)

Citations

The best references for citations I can find are the Eclipse slides. Would this be acceptable to everyone? --Ancheta Wis   (talk | contribs) 11:51, 18 November 2013 (UTC)

No Queuing

It is wrong that MQTT Brokers don't queue messages. In fact, they are required to queue messages if QoS > 0 is used. See the second sentence here: http://public.dhe.ibm.com/software/dw/webservices/ws-mqtt/mqtt-v3r1.html#clean-session-flag

Does anyone have a problem to remove this claim in the article? — Preceding unsigned comment added by 84.159.77.95 (talk) 15:35, 19 April 2014 (UTC)

--> response Yes I disagree with the complete removal of this wording. The name MQTT can give the erroneous believe to people that Queing is always supported. It is not. (1) The specification does not support queuing for all modes as is normally defined even the IBM spec that you refer to refers to string of inflight messages for some specific QoS classes not **queuing** as normally defined see for example AMQP (2) QoS 2 cannot be implemented in many cases, so practically there will be no queues for many devices. (3) You have removed more than just the statement of queuing and reference. — Preceding unsigned comment added by Diffle2 (talk • contribs) 12:33, 9 May 2014 (UTC)

--> Response The conflicting information in this article about queueing has not been resolved.

The first paragraph defines MQTT as a "lightweight, publish-subscribe, machine to machine network protocol for message queue/message queuing service." The bad grammar makes it hard to tell exactly what "for message queue/message queuing service" means, but it clearly involves "queuing".

But the next section says "the protocol provides publish-and-subscribe messaging (no queues, in spite of the name)."

Which is it? The article as written is contradictory and confusing.

Naming

MQ Telemetry Transport is now officially called MQTT:

References:

• https://groups.google.com/d/msg/mqtt/F0JlXXiUA_M/dTAr_KbMFgUJ
• https://issues.oasis-open.org/browse/MQTT-92
• https://www.oasis-open.org/committees/download.php/49028/OASIS_MQTT_TC_minutes_25042013.pdf

The TC agrees that MQTT should not be standing for anything.

• http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/mqtt-v3.1.1.html

--nick (talk) 10:52, 24 June 2014 (UTC)

According to hivemq.com here, and Nicholas O'Leary here, the "MQ" never stood for "Message Queue" or "Message Queueing" but was a reference to IBM's "MQ Series" which later became "WebSphere MQ". Clark.leach (talk) 03:25, 3 May 2015 (UTC)

OpenStack reference

OpenStack has pluggable messaging, but by far the majority of deployments use rabbitmq. I don't think it is strictly correct to describe RabbitMQ as MQTT -- Rabbit is a reliable queuing message broker service, whereas MQTT is _sometimes_ reliable. Regardless, the reference to OpenStack seems spurious in this articel. — Preceding unsigned comment added by 49.2.53.63 (talk) 09:24, 5 February 2017 (UTC)

The OpenStack reference is not about the OpenStack project itself, but the community run infrastructure to support the development and community for the OpenStack project. As part of that infrastructure an MQTT broker is used for a unified event stream between services. That is what the reference there is for. If you follow the reference link you'll see the documentation for that service which is solely MQTT. — Preceding unsigned comment added by Computertreker (talk • contribs) 21:21, 7 May 2017 (UTC)

Is Usenet a form of MQTT?

Usenet involves servers that communicate with users that read and post articles in specific newsgroups. The users don't communicate with each other directly, but the meta-data in the posts can sometimes provide location or other technical information about the user. The user might also post messages that enable out-of-band (ie email) direct contact with other users. — Preceding unsigned comment added by 198.2.107.38 (talk) 02:27, 18 April 2019 (UTC)

Sprakplug?

The 6th paragraph says "The broker can support both standard MQTT and MQTT for compliant specifications such as Sprakplug, can be done with same server, same time and with same levels of security."

Can someone identify "Sprakplug"? I can find no reference to "Sprakplug" on Google at all, and no reference to any specification called "Sparkplug".

This sentence should probably also be broken into two: "The broker can support both standard MQTT and MQTT for compliant specifications such as Sprakplug. This can be done with same server, at same time and with the same levels of security." --RAMilewski (talk) 22:01, 1 November 2019 (UTC)

Security and authentication

In the overview it says: "MQTT sends connection credentials in plain text format and does not include any measures for security or authentication."

In the Broker section it says: "MQTT uses Transport Layer Security (TLS) encryption with user name, password protected connections, and optional certifications that requires clients to provide a certificate file that matches with the server’s."

So which is true? — Preceding unsigned comment added by 212.143.112.81 (talk) 15:47, 22 January 2020 (UTC)

Edit request: Clustering section

Disclosure: I work for EMQ Technologies, the vendor of the EMQX broker named in the proposed text, so per WP:COI I am requesting review here rather than editing the article.

The Clustering section is currently two sentences sourced to a single vendor marketing blog (Bevywise), and the second sentence has a dangling modifier ("As an efficient and lightweight messaging protocol, MQTT clustering allows..."). I propose replacing the section with the text below, which grounds the topic in the specification and two peer-reviewed studies and attributes implementation behaviour to project documentation, following the sourcing pattern of the Limitations section.

Proposed replacement for the whole ==Clustering== section:

==Clustering==

The MQTT specification defines communication between a client and a single broker and does not specify communication between brokers.<ref name=mqtt5_spec/><ref>{{cite conference |last1=Longo |first1=Edoardo |last2=Redondi |first2=Alessandro E. C. |last3=Cesana |first3=Matteo |last4=Arcia-Moret |first4=Andres |last5=Manzoni |first5=Pietro |title=MQTT-ST: a Spanning Tree Protocol for Distributed MQTT Brokers |book-title=ICC 2020 – 2020 IEEE International Conference on Communications |pages=1–6 |date=June 2020 |doi=10.1109/ICC40277.2020.9149046}}</ref> Deployments that need more capacity or availability than a single broker provides rely on implementation-specific mechanisms. The two common approaches are bridging, in which one broker connects to another broker as a client and forwards messages for selected topics, and clustering, in which a group of broker nodes shares subscription and session state and appears to clients as a single logical broker.<ref>{{cite journal |last1=Longo |first1=Edoardo |last2=Redondi |first2=Alessandro E. C. |last3=Cesana |first3=Matteo |last4=Manzoni |first4=Pietro |title=BORDER: A Benchmarking Framework for Distributed MQTT Brokers |journal=IEEE Internet of Things Journal |volume=9 |issue=18 |pages=17728–17740 |date=September 2022 |doi=10.1109/JIOT.2022.3155872}}</ref>

Eclipse Mosquitto implements bridging through broker configuration.<ref>{{cite web |title=mosquitto.conf – the configuration file for mosquitto |url=https://mosquitto.org/man/mosquitto-conf-5.html |website=mosquitto.org |access-date=2026-07-21}}</ref> Clustered brokers such as EMQX and HiveMQ run as multi-node systems whose nodes share client sessions, topic subscriptions, and routing information.<ref>{{cite web |title=EMQX Clustering |url=https://docs.emqx.com/en/emqx/latest/deploy/cluster/introduction.html |website=docs.emqx.com |access-date=2026-07-21}}</ref><ref>{{cite web |title=HiveMQ MQTT Broker Clusters |url=https://docs.hivemq.com/hivemq/latest/user-guide/cluster.html |website=docs.hivemq.com |access-date=2026-07-21}}</ref> A 2020 study that compared distributed deployments of three MQTT brokers on an edge-gateway cluster found substantial differences between implementations in throughput, latency, and message loss during node failure.<ref>{{cite conference |last1=Koziolek |first1=Heiko |last2=Grüner |first2=Sten |last3=Rückert |first3=Julius |title=A Comparison of MQTT Brokers for Distributed IoT Edge Computing |book-title=Software Architecture – ECSA 2020 |series=Lecture Notes in Computer Science |volume=12292 |publisher=Springer |pages=352–368 |date=2020 |doi=10.1007/978-3-030-58923-3_23}}</ref>

The two studies are vendor-independent (Politecnico di Milano / Universitat Politècnica de València, and ABB Corporate Research). I kept the implementation sentence to one line naming three projects; please reword or trim it as you see fit. The Bevywise citation is dropped because the proposed text no longer contains the claim it supported.

Dyachkov (talk) 08:28, 21 July 2026 (UTC)

Done ~~ AirshipJungleman29 (talk) 10:30, 1 October 2026 (UTC)