In a class I am attending for Dr.Imran Zulkernan for advanced internet computing we were discussing a very interesting topic for message oriented middle-wares using both publish subscribe and request response mechanisms, we were assigned an exciting homework to compare both XMPP & MQTT-SN middle-wares for use in IoT applications. I wanted to share the results and hope that it may come in handy for your decision if you are interested in this topic.
MQTT-SN: Message Queuing Telemetry Transport (MQTT) is an open pub/sub protocol. MQTT-SN is an extension of the open publish/subscribe protocol designed for constrained devices used in telemetry applications. [2]
XMPP: Extensible Messaging and Presence Protocol (XMPP), which is standardized by the IETF and widely deployed for real-time data stream and Instant Messaging (IM) applications. XMPP itself is a set of flexible and open XML technologies that are expandable by protocol extensions (XEPs) to adopt to various environments
and scenarios. [1]
| Criteria | XMPP | MQTT-SN |
|---|---|---|
| Suitable for Devices with limited ROM resources | Has a modified version called uXMPP which has reduced functionality & the output code is around 12.21 kb | Full implementation is 12 kb but it can be reduced further by implementing predefined topic IDs |
| Addressing Single Devices | The devices can be directly addressed and messages can be identified from by the jabber ID of the device | Devices are publishing topics and only the broker identifies the device for QOS reasons but the subscriber doesn’t get the device id by default, rather the subscriber get the topic contents aggregated from one or multiple devices |
| Addressing Multiple Devices | XEP implementation XEP-0045 can help in addressing multiple devices using a chat room, but these chat rooms cannot be addressed in a hierarchal fashion. If we need devices in the same floor they all need to be in a chat room, and if these same devices needs to be grouped to include all the building these devices need to be also joined to a different chat room including all devices in the building | Devices are publishing topics and topics can be addressed in a hierarchal fashion, there are wildcards supported that can select multiple topics such as multiple room temperatures for a certain floor and room temperatures for the whole building |
| Actuator Control | Device can be identified by jabber id and control message can directly reach the destination device | Device needs to be subscribed to a control topic and the control message needs to be published to the same topic |
| Main Method for providing readings | Based on the event of receiving a message, but can be extended to publish-subscribe with XEP-0060 | Polling where the device needs to continuously provide readings to the subscriber within a certain time interval & can be based on certain conditions. A workaround can be done by making the device subscribe to a topic and publish based on a message received from a topic |
| Data exchange format | XML Stanzas, where the device can publish multiple attributes along with headers but it will add additional overhead in the message packet | Content can be stored in the packet for the topic in any format and can be very lightweight |
| Failover mechanisms | uXMPP is using the XEP standard XEP-0174 Serverless Messaging via Multicast DNS (mDNS) and DNS Service Discovery
(DNS-SD) for directly sending messages to the device without an XMPP server which is a failover mechanism in case the XMPP server is down |
In MQTT-SN the device has to communicate with a gateway and a broker for the topic to reach the subscriber, no backup mechanism presented |
| Power saving | XMPP can make the device wake up for many times unnecessarily when requesting for data, the extension XEP-0060 can help in resolving that and making it join a chatroom | MQTT-SN can help the device stay in sleep mode and publish only in certain conditions without being invoked to wake up and send data |
| Changing devices | XMPP gets affected when changing devices because the new jabber id needs to be configured, the dynamic and up-to-date roster is a workaround to overcome this limitation | As the devices publish topics, the subscriber doesn’t care if the device changed because the topic will remain the same |
| QoS | Not available by default but can be added | Handles QoS and has 3 levels |
| Security | XMPP supports TLS/SSL, but uXMPP doesn’t currently support it | Security is not available in the standard but the messages can be encrypted |
| Scalability | XMPP can be scalable by extending the XMPP server to multiple servers connected together where the message can travel from one server to another | Scalability is limited by the number of devices that can be connected to the gateway and the number of gateways that can be connected to the broker |
Type of applications suited for XMPP:
- Actuator networks where identifying each device by its address rather than the topic is important to send control signals to the device.
- Scenarios where the middleware is not reliable and failover mechanism is required
- Simple Human-Machine interaction where the human can type control messages to get the required data such as sending a query to a certain device to get the current image of the connected camera.
- In Feature rich IoT applications such as home automation XMPP is suitable due to the available XEPs that extend the protocol
- Applications where network is stable and QoS is not very important
- Applications where integrations with third party solutions from different vendors are required, as XMPP relies on XML as a messaging format, third party solutions can easily adapt to it
- Applications where security is a concern and TLS/SSL standards needs to be followed
- When the IoT device has many readings and actuator functionality where they can be easily addressed by the XML format where in XMPP it is the standard and only format, applications similar to getting readings from smartphones where it has multiple sensors where the data can be easily expressed in XML
Type of applications suited for MQTT-SN:
- Large number of temperature sensors distributed in rooms across different buildings for HVAC control, due to the publish-subscribe mechanism which is mostly suitable for this application
- Highly constrained devices with limited power that communicate over low bandwidth network
- Fleet management where the subscriber can subscribe to topics sending GPS locations of grouped devices and monitoring their location on certain interval
- Applications where the scope is limited such as getting temperature readings for an area
- Applications where the network quality and performance is low and failures are high, QoS in MQTT-SN helps manage the arrival of messages
- Suitable for smart-grid applications for getting meter readings from homes where the meters have very limited processing powers
- Applications such as fire alarms where the sensor needs to be sleeping most of the time and will send readings based on a certain event
References:
[1] Klauck, R.; Kirsche, M., “Chatty things – Making the Internet of Things readily usable for the masses with XMPP,” Collaborative Computing: Networking, Applications and Worksharing (CollaborateCom), 2012 8th International Conference on , vol., no., pp.60,69, 14-17 Oct. 2012
[2] Hunkeler, U.; Hong Linh Truong; Stanford-Clark, A., “MQTT-S — A publish/subscribe protocol for Wireless Sensor Networks,” Communication Systems Software and Middleware and Workshops, 2008. COMSWARE 2008. 3rd International Conference on , vol., no., pp.791,798, 6-10 Jan. 2008
http://www.iotprimer.com/2013/11/iot-protocol-wars-mqtt-vs-coap-vs-xmpp.html
http://stackoverflow.com/questions/7129821/mqtt-vs-xmpp-which-should-i-choose
XMPP vs MQTT-S for IoT Applications http://t.co/wleI1IHu26
— Mohammed Al-Solh (@alsolh) April 30, 2014