O'Reilly logo

XMPP: The Definitive Guide by Remko Tronçon, Kevin Smith, Peter Saint-Andre

Stay ahead with the world's most comprehensive technology and business learning platform.

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training, learning paths, books, tutorials, and more.

Start Free Trial

No credit card required

Chapter 4. Instant Messaging

I Think, Therefore IM

The initial goal of the early Jabber project, well before the protocol was named XMPP, was to create an open Instant Messaging (IM) platform. Although IM is often thought of as person-to-person chat, at its core it really provides the ability to quickly route messages from one place to another over the network (no matter who or what the intended recipient is). For this reason, XMPP servers are optimized for handling large numbers of relatively small messages with very little latency. When you are exchanging instant messages, you don’t want to experience any delivery delays (which can be almost as annoying in IM as they are on the phone).

In XMPP, messages are delivered as fast as possible over the network. Let’s say that Alice sends a message from her new account on the wonderland.lit server to her sister on the realworld.lit server. Her client effectively “uploads” the message to wonderland.lit by pushing a message stanza over a client-to-server XML stream. The wonderland.lit server then stamps a from address on the stanza and checks the to address in order to see how the stanza needs to be handled (without performing any deep packet inspection or XML parsing, since that would eat into the delivery time). Seeing that the message stanza is bound for the realworld.lit server, the wonderland.lit server then immediately routes the message to realworld.lit over a server-to-server XML stream (with no intermediate hops). Upon receiving the message stanza, the realworld.lit server checks to see whether Alice’s sister is online; if so, the server immediately delivers the message to one or more of her online devices over a server-to-client XML stream (without storing it or otherwise performing much processing on it). As a result, the message is delivered very quickly from Alice to her sister.

These design decisions have important implications. First and foremost, the clients and servers need to be event-driven and ready to take appropriate action whenever they receive an incoming stanza. XMPP servers don’t have the luxury of storing a message and waiting for a client to poll for it; instead, they deliver the message as soon as they receive it. Second, all entities (but especially the servers) need to be presence-aware, since it is the concept of being online that makes rapid delivery possible in the crucial “last mile” between the recipient’s server and the recipient’s device(s). Third, fast and accurate handling of DNS lookups, domain name resolution, long-lived TCP connections, connectivity outages, and network congestion is critical to the success of the overall system.

Several types of XMPP messages exist, fundamentally differentiated by the value of the type attribute:


This message type is delivered immediately or stored offline by the server, and handled by the client as a “standalone” message outside of any chat or groupchat session. This is the default message type.


Messages of type chat are sent within a burst of messages called a “chat session,” usually over a relatively short period of time. Instant messaging clients show such messages in a one-to-one conversation interface for the two parties.


XMPP servers usually route messages of type groupchat to a specialized component or module that hosts multi-user chat rooms, and this component then generates one outbound message for each of the room occupants. (We discuss groupchat messages in Chapter 7.)


Headline messages usually are not stored offline, because they are temporal in nature. In addition, XMPP servers often send a message of type headline to all of the online devices associated with an account (at least those with non-negative <priority/> values).


A message of type error is sent in response to a previously sent message, to indicate that a problem occurred in relation to the earlier message (the recipient does not exist, message delivery is not possible at the moment, etc.).

Both chat and normal messages are usually handled by the recipient’s server in a particular way: if the message is addressed to the bare JID (user@domain.tld) of the account, the server immediately delivers the message to the highest-priority resource currently associated with the account. If there is only one online resource, this decision is easy, but if there are multiple online resources, the recipient’s server delivers the message to the resource with the largest value for its presence priority. For example, a resource with a presence priority of 7 will receive messages addressed to the bare JID, but another resource with a presence priority of 3 will not. (Resources with negative priority will never receive a message sent to the bare JID, but all resources will receive a message addressed to the full JID of that resource.)

Finally, although XMPP technologies put a premium on near real-time data delivery, almost all XMPP servers include support for “offline messages” if the intended recipient is not online when the server receives a normal or chat message addressed to that JabberID. These messages are automatically pushed to the recipient’s client when the user next logs in. When the recipient’s server pushes out the offline message, it also adds a small extension noting when the message was originally received, using the protocol extension defined in Delayed Delivery XEP-0203. This enables the recipient’s client to properly order the messages it receives in a user interface.

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training, learning paths, books, interactive tutorials, and more.

Start Free Trial

No credit card required