Devices and users exchange messages in Xively over the messaging service, which is an MQTT broker, designed for scalability to very large numbers of devices and message rates, while providing extremely low latencies.
Never heard of MQTT? Here's a simple explanation of why MQTT is the protocol of choice for the IoT.
MQTT is a light weight, asynchronous and open client-server publish/subscribe messaging transport protocol designed for easy implementation.
A user and device connect to the broker and exchange a message.
It usually runs over TCP/IP, or over other network protocols that provide ordered, lossless, bi-directional connections. These characteristics make it ideal for use in many situations, including constrained environments such as for communication in Machine to Machine (M2M) and Internet of Things (IoT) contexts where a small code footprint is required and/or network bandwidth is at a premium.
As of October 29th 2014, MQTT is an approved OASIS standard.
The broker implements the MQTT specification as follows:
- MQTT 3.1.1 compliant broker
- Quality of Service (QoS) 0 and 1 are supported. Subscribers requesting QoS1 delivery for messages published at QoS0 will get QoS0 delivery.
- Topics are not ordered. The order messages are received by a subscriber may not match the order they were published.
- Wildcards are not supported. All topics names must refer to specific topics.
MQTT's publish/subscribe model differs from traditional client-server connections, because the publisher and subscriber entities are usually unaware of each other and do not address each other directly. Instead, messages published by a device to certain MQTT channels are routed to subscribers by Xively's MQTT broker, based on the current state of topic subscriptions and permissions set within Xively. This infrastructure provides a lightweight and bandwidth efficient way to send and receive data, as individual clients do not need to keep track of numerous connections, maintain the state of connections to multiple parties or deal with the overhead of broadcasting messages.
- Multiple methods (PUT, POST, PATCH, DELETE, GET)
- Packet over the wire is bigger
- HTTP server/libs can be pretty big
- Byte array (don’t care payload)
- Two methods (PUB, SUB)
- Packet size as small as 2 bytes
- 1-to-none, 1-to-1, 1-to-many
- Data can be retained on a topic so devices receive the information immediately upon connection
- Lightweight MQTT libs are much better suited for small microcontrollers
Dive in to working with MQTT
|Connecting and Disconnecting|