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)