XMPP/Jabber for IoT Devices - Part 1

Recently we implemented XMPP (or Jabber) support into our IoT Device Management Framework. Ideally this provides near realtime communication between multiple devices over multiple networks. The architecture of the Jabber server is conforms to an email server(server.com) where XMPP clients conforms email clients(user@server.com). Many chat clients implements XMPP to communicate between distributed networks near realtime.

Earlier we had the assumption of each device always have an accessible IP address. Based on this assumption we had an HTTP server running on the client-side. The APIs on the IoT Device Framework can call HTTP server on the device and perform actuators and sensor readings.

HTTP server based implementation

What's wrong with HTTP?

Let me explain why this doesn't work all time. Suppose you need to make your devices controllable through IoT Device Framework APIs over Internet. One option is to provide public IPs into each device. Oh God!, it is not a good solution.

Then other option is NAT. The devices are exposed into Internet over a NAT gateway. Outgoing messages from the device will be modified by NAT gateway so that they appear to be coming from the NAT gateway itself. The NAT gateway will record the changes it makes in its state table so that it can reverse the changes on return packets. NATs will keep the association for as long as the connection is alive. When your API calls returning into NAT gateway, Gateway itself might not be able to find return destination.

How NAT works (photo courtesy of How Stuff Works)

How XMPP handle it?

Let's see how XMPP can handle this. XMPP is the Internet Standard for real time messaging communication and presence. It uses a standard TCP connection. You can use fully-fledged light-weight XMPP pings (XEP-0199) to keep NAT records alive. Need to notice that XMPP can be also implemented over HTTP too(BOSH). Prime advantage of the XMPP is that you can address a device on "user@server.com/mobile" resource addressing scheme instead of IP of the device. XMPP can act

XMPP's basic model of communication is Client -> Server -> Server -> Client, and in support of this it defines a Client to Server protocol and a Server to Server protocol. Both of these protocols use XML encoded protocol directly over TCP. XMPP is a Bi-directional stream and "non-blocking":uses event-driven style. Powerful XMPP extensions such as Pub-Sub(XEP060) are available out-of-the box.

HTTP polling vs XMPP PubSub(source: [1])

How XMPP works?

The major steps for server-to-client communication as follows;

Client and server communicate through port 5222 via a TCP connection.
XMPP informations are contained on XML streams. A XMPP session is opened by <stream> tag and ended by </stream> tag. All other parts are located between them.
For security purpose, the open stream is followed by moderate Transport Layer Security (TLS) negotiation and compulsory Simple Authentication and Security Layer (SASL) negotiation.
A new stream will be opened immediately after the SASL negotiation, and it will be more secure and safe.

Please refer this post for more detail explanation.

XMPP Network Architecture

The next blog-post will describe how you can configure XMPP client and a server based on unofficial official XMPP IoT devices standard.

Links:
[1] http://www.slideshare.net/igrigorik/event-driven-architecture-meshu-ilya-grigorik