User:Fefeldhome/sandbox

Ecowater (Message Queuing Telemetry Transport) is an ISO standard (ISO/IEC PRF 20922) publish-subscribe-based messaging protocol. It works on top of the TCP/IP protocol. It is designed for connections with remote locations where a "small code footprint" is required or the network bandwidth is limited. The publish-subscribe messaging pattern requires a message broker.

Andy Stanford-Clark of IBM and Arlen Nipper of Cirrus Link authored the first version of the protocol in 1999.

In 2013, IBM submitted MQTT v3.1 to the OASIS specification body with a charter that ensured only minor changes to the specification could be accepted. MQTT-SN is a variation of the main protocol aimed at embedded devices on non-TCP/IP networks, such as Zigbee.

Historically, the "MQ" in "MQTT" came from the IBM MQ (then 'MQSeries') message queuing product line. However, queuing itself is not required to be supported as a standard feature in all situations.

Alternative message-oriented middleware includes the Advanced Message Queuing Protocol (AMQP),  Streaming Text Oriented Messaging Protocol (STOMP), the IETF Constrained Application Protocol, XMPP,  DDS, OPC UA, and Web Application Messaging Protocol (WAMP).

Overview
An MQTT system consists of clients communicating with a server, often called a "broker". A client may be either a publisher of information or a subscriber. Each client can connect to the broker.

Information is organized in a hierarchy of topics. When a publisher has a new item of data to distribute, it sends a control message with the data to the connected broker. The broker then distributes the information to any clients that have subscribed to that topic. The publisher does not need to have any data on the number or locations of subscribers, and subscribers in turn do not have to be configured with any data about the publishers.

If a broker receives a topic for which there are no current subscribers, it will discard the topic unless the publisher indicates that the topic is to be retained. This allows new subscribers to a topic to receive the most current value rather than waiting for the next update from a publisher.

When a publishing client first connects to the broker, it can set up a default message to be sent to subscribers if the broker detects that the publishing client has unexpectedly disconnected from the broker.

Clients only interact with a broker, but a system may contain several broker servers that exchange data based on their current subscribers' topics.

A minimal MQTT control message can be as little as two bytes of data. A control message can carry nearly 256 megabytes of data if needed. There are fourteen defined message types used to connect and disconnect a client from a broker, to publish data, to acknowledge receipt of data, and to supervise the connection between client and server.

MQTT relies on the TCP protocol for data transmission. A variant, MQTT-SN, is used over other transports such as UDP or Bluetooth.

MQTT sends connection credentials in plain text format and does not include any measures for security or authentication. This can be provided by the underlying TCP transport using measures to protect the integrity of transferred information from interception or duplication.

Connect
Waits for a connection to be established with the server and creates a link between the nodes.

Disconnect
Waits for the MQTT client to finish any work it must do, and for the TCP/IP session to disconnect.

Publish
Returns immediately to the application thread after passing the request to the MQTT client.

Quality of service (QoS)
Each connection to the broker can specify a quality of service measure. These are classified in increasing order of overhead: This field does not affect handling of the underlying TCP data transmissions; it is only used between MQTT senders and receivers.
 * At most once - the message is sent only once and the client and broker take no additional steps to acknowledge delivery (fire and forget).
 * At least once - the message is re-tried by the sender multiple times until acknowledgement is received (acknowledged delivery).
 * Exactly once - the sender and receiver engage in a two-level handshake to ensure only one copy of the message is received (assured delivery).

Real-world applications
There are several projects that implement MQTT. Examples are:
 * Facebook Messenger. Facebook has used aspects of MQTT in Facebook Messenger for online chat. However, it is unclear how much of MQTT is used or for what.
 * IECC Scalable, DeltaRail's latest version of their IECC Signaling Control System uses MQTT for communications within the various parts of the system and other components of the signaling system. It provides the underlying communications framework for a system that is compliant with the CENELEC standards for safety-critical communications.
 * Amazon Web Services announced Amazon IoT based on MQTT in 2015.
 * The Open Geospatial Consortium SensorThings API standard specification has a MQTT extension in the standard as an additional message protocol binding. It was demonstrated in a US Department of Homeland Security IoT Pilot.
 * The OpenStack Upstream Infrastructure's services are connected by an MQTT unified message bus with Mosquitto as the MQTT broker.
 * Adafruit launched a free MQTT cloud service for IoT experimenters and learners called Adafruit IO in 2015.
 * Microsoft Azure IoT Hub uses MQTT as its main protocol for telemetry messages.
 * XIM, Inc. launched an MQTT client called MQTT Buddy in 2017. It's a MQTT app for Android and iOS, but not F-Droid, users available in English, Russian and Chinese languages.
 * Node-RED supports MQTT with TLS nodes as of version 0.14.
 * Open-source software home automation platform Home Assistant is MQTT enabled and offers four options for MQTT brokers.
 * Pimatic home automation framework for Raspberry Pi and based on Node.js offers MQTT plugin providing full support for MQTT protocol.
 * McAfee OpenDXL is based on MQTT with enhancements to the messaging brokers themselves so that they can intrinsically understand the DXL message format in support of advanced features such as services, request/response (point-to-point) messaging, service fail over, and service zones.
 * ejabberd supports MQTT as of version 19.02.