| <?php include '../_includes/header.php' ?><div class="refentry"> |
| <a name="mqtt"></a><div class="titlepage"></div> |
| <div class="refnamediv"> |
| <h2>Name</h2> |
| <p>mqtt — MQ Telemetry Transport</p> |
| </div> |
| <div class="refsynopsisdiv"> |
| <h2>Synopsis</h2> |
| <div class="cmdsynopsis"><p><code class="command">MQTT</code> </p></div> |
| </div> |
| <div class="refsect1"> |
| <a name="idp48957168"></a><h2>Description</h2> |
| <p><span class="command"><strong>MQTT</strong></span> is a lightweight publish/subscribe |
| messaging protocol. It is useful for use with low power sensors, but |
| is applicable to many scenarios.</p> |
| <p>This manual describes |
| some of the features of MQTT version 3.1, to assist end users in |
| getting the most out of the protocol. For more complete information on |
| MQTT, see <code class="uri">http://mqtt.org/</code>.</p> |
| </div> |
| <div class="refsect1"> |
| <a name="idp48959824"></a><h2>Publish/Subscribe</h2> |
| <p>The MQTT protocol is based on the principle of publishing |
| messages and subscribing to topics, or "pub/sub". Multiple clients |
| connect to a broker and subscribe to topics that they are interested |
| in. Clients also connect to the broker and publish messages to topics. |
| Many clients may subscribe to the same topics and do with the |
| information as they please. The broker and MQTT act as a simple, common |
| interface for everything to connect to. This means that you if you have |
| clients that dump subscribed messages to a database, to Twitter, |
| Cosm or even a simple text file, then it becomes very simple to add |
| new sensors or other data input to a database, Twitter or so on.</p> |
| </div> |
| <div class="refsect1"> |
| <a name="idp48961680"></a><h2>Topics/Subscriptions</h2> |
| <p>Messages in MQTT are published on topics. There is no need to |
| configure a topic, publishing on it is enough. Topics are treated as a |
| hierarchy, using a slash (/) as a separator. This allows sensible |
| arrangement of common themes to be created, much in the same way as a |
| filesystem. For example, multiple computers may all publish their |
| hard drive temperature information on the following topic, with their |
| own computer and hard drive name being replaced as appropriate:</p> |
| <div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; "><li class="listitem"><p>sensors/COMPUTER_NAME/temperature/HARDDRIVE_NAME</p></li></ul></div> |
| <p>Clients can receive messages by creating subscriptions. A |
| subscription may be to an explicit topic, in which case only messages |
| to that topic will be received, or it may include wildcards. Two |
| wildcards are available, <code class="option">+</code> or <code class="option">#</code>.</p> |
| <p><code class="option">+</code> can be used as a wildcard for a single level |
| of hierarchy. It could be used with the topic above to get information |
| on all computers and hard drives as follows:</p> |
| <div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; "><li class="listitem"><p>sensors/+/temperature/+</p></li></ul></div> |
| <p>As another example, for a topic of "a/b/c/d", the following |
| example subscriptions will match:</p> |
| <div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: circle; "> |
| <li class="listitem" style="list-style-type: circle"><p>a/b/c/d</p></li> |
| <li class="listitem" style="list-style-type: circle"><p>+/b/c/d</p></li> |
| <li class="listitem" style="list-style-type: circle"><p>a/+/c/d</p></li> |
| <li class="listitem" style="list-style-type: circle"><p>a/+/+/d</p></li> |
| <li class="listitem" style="list-style-type: circle"><p>+/+/+/+</p></li> |
| </ul></div> |
| <p>The following subscriptions will not match:</p> |
| <div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: circle; "> |
| <li class="listitem" style="list-style-type: circle"><p>a/b/c</p></li> |
| <li class="listitem" style="list-style-type: circle"><p>b/+/c/d</p></li> |
| <li class="listitem" style="list-style-type: circle"><p>+/+/+</p></li> |
| </ul></div> |
| <p><code class="option">#</code> can be used as a wildcard for all remaining levels of |
| hierarchy. This means that it must be the final character in a |
| subscription. With a topic of "a/b/c/d", the following example |
| subscriptions will match:</p> |
| <div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: circle; "> |
| <li class="listitem" style="list-style-type: circle"><p>a/b/c/d</p></li> |
| <li class="listitem" style="list-style-type: circle"><p>#</p></li> |
| <li class="listitem" style="list-style-type: circle"><p>a/#</p></li> |
| <li class="listitem" style="list-style-type: circle"><p>a/b/#</p></li> |
| <li class="listitem" style="list-style-type: circle"><p>a/b/c/#</p></li> |
| <li class="listitem" style="list-style-type: circle"><p>+/b/c/#</p></li> |
| </ul></div> |
| <p>Zero length topic levels are valid, which can lead to some |
| slightly non-obvious behaviour. For example, a topic of "a//topic" |
| would correctly match against a subscription of "a/+/topic". |
| Likewise, zero length topic levels can exist at both the beginning |
| and the end of a topic string, so "/a/topic" would match against a |
| subscription of "+/a/topic", "#" or "/#", and a topic "a/topic/" |
| would match against a subscription of "a/topic/+" or |
| "a/topic/#".</p> |
| </div> |
| <div class="refsect1"> |
| <a name="idp48978544"></a><h2>Quality of Service</h2> |
| <p>MQTT defines three levels of Quality of Service (QoS). The QoS |
| defines how hard the broker/client will try to ensure that a message is |
| received. Messages may be sent at any QoS level, and clients may |
| attempt to subscribe to topics at any QoS level. This means that the |
| client chooses the maximum QoS it will receive. For example, if a |
| message is published at QoS 2 and a client is subscribed with QoS 0, |
| the message will be delivered to that client with QoS 0. If a second |
| client is also subscribed to the same topic, but with QoS 2, then it |
| will receive the same message but with QoS 2. For a second example, if |
| a client is subscribed with QoS 2 and a message is published on QoS 0, |
| the client will receive it on QoS 0.</p> |
| <p>Higher levels of QoS are more reliable, but involve higher |
| latency and have higher bandwidth requirements.</p> |
| <div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; "> |
| <li class="listitem"><p>0: The broker/client will deliver the message once, with no confirmation.</p></li> |
| <li class="listitem"><p>1: The broker/client will deliver the message at least once, with confirmation required.</p></li> |
| <li class="listitem"><p>2: The broker/client will deliver the message exactly once by using a four step handshake.</p></li> |
| </ul></div> |
| </div> |
| <div class="refsect1"> |
| <a name="idp48982880"></a><h2>Retained Messages</h2> |
| <p>All messages may be set to be retained. This means that the |
| broker will keep the message even after sending it to all current |
| subscribers. If a new subscription is made that matches the topic of |
| the retained message, then the message will be sent to the client. This |
| is useful as a "last known good" mechanism. If a topic is only updated |
| infrequently, then without a retained message, a newly subscribed |
| client may have to wait a long time to receive an update. With a |
| retained message, the client will receive an instant update.</p> |
| </div> |
| <div class="refsect1"> |
| <a name="idp48984592"></a><h2>Clean session / Durable connections</h2> |
| <p>On connection, a client sets the "clean session" flag, which is |
| sometimes also known as the "clean start" flag. If clean session is set |
| to false, then the connection is treated as durable. This means that |
| when the client disconnects, any subscriptions it has will remain and |
| any subsequent QoS 1 or 2 messages will be stored until it connects |
| again in the future. If clean session is true, then all subscriptions |
| will be removed for the client when it disconnects.</p> |
| </div> |
| <div class="refsect1"> |
| <a name="idp48986240"></a><h2>Wills</h2> |
| <p>When a client connects to a broker, it may inform the broker that |
| it has a will. This is a message that it wishes the broker to send when |
| the client disconnects unexpectedly. The will message has a topic, |
| QoS and retain status just the same as any other message.</p> |
| </div> |
| <div class="refsect1"> |
| <a name="idp48987680"></a><h2>See Also</h2> |
| <span class="simplelist"> |
| <span class="citerefentry"><span class="refentrytitle"><a class="link" href="mosquitto-8.php" target="_top">mosquitto</a></span>(8)</span> |
| , |
| <span class="citerefentry"><span class="refentrytitle"><a class="link" href="mosquitto_pub-1.php" target="_top">mosquitto_pub</a></span>(1)</span> |
| , |
| <span class="citerefentry"><span class="refentrytitle"><a class="link" href="mosquitto_sub-1.php" target="_top">mosquitto_sub</a></span>(1)</span> |
| </span> |
| </div> |
| <div class="refsect1"> |
| <a name="idp48994336"></a><h2>Author</h2> |
| <p>Roger Light <code class="email"><<a class="email" href="mailto:roger@atchoo.org">roger@atchoo.org</a>></code></p> |
| </div> |
| </div><?php include '../_includes/footer.php' ?> |