Version 1

    The Extensible Messaging and Presence Protocol (XMPP) is an open standard and TCP communications protocol that was intended to transmit numerous minor snippets of XML data over a decentralized network in near real time. XMPP was first called Jabber in the late 1990s; it was used for instant messaging. But it can power a range of applications besides instant messaging, including multi-party chat, voice & video calls, collaboration, and general routing of XML data. XMPP-IoT is a version that allows the sending and receiving of messages from machines.



    XMPP has the following benefits over HTTP:


    • Firewall friendly: XMPP connections are firewall and network address translation (NAT) friendly. Once a connection is established, the server can push all the data it needs to the client.
    • Enables pushing data, not just pulling: In HTTP, the server can only send data after a request from the client. In the XMPP, server and client can send data to each other any time, as long as the connection is open. Applications can receive notifications whenever new information is available. This ability to push data expands the possibilities for protocol design and web applications.
    • Strong authentication and security: XMPP is built on top of Transport Layer Security (TLS) and Simple Authentication and Security Layer protocol (SASL) technologies, which provide strong encryption and security for XMPP connections. TLS encrypts XML streams to ensure the confidentiality and data integrity between two entities, and SASL can provide a reliable mechanism for validating the identity of an entity.
    • Provides many tools for solving a wide range of problems: HTTP provides support for only a handful of operations — GET, PUT, POST, DELETE, and so on. XMPP includes three different low-level tools, <presence>, <message>, and <iq> stanzas, and almost 300 extensions that compose these tools into sophisticated protocols.



    With the above benefits, XMPP can be used in the following applications:


    • Cloud computing/IoT: XMPP with its extensions is a great protocol for cloud services in the emerging Internet of Things. It exhibits real-time capabilities such as alarms, log processing, asynchronous web services, and effective distribution of data (e.g., publish/subscribe, direct push configuration distribution, push RSS/Atom, data collection, Federated services & discovery, Easy inter-domain RPCs, and access control based on JID and advanced detection capabilities not available in HTTP-based web services).
    • Social networking: The primary attraction here is that XMPP overcomes the major scaling issues related to constantly polling for updated information. It’s substantially more effective in treating location sharing, microblogging, and social music services as types of on-demand micro-messaging than dynamic websites that must be continually surveyed for updates.
    • Voice, video, and other multimedia sessions: XMPP is not used for transmitting bandwidth-consuming data such as voice and video, but it is nearly ideal for handling such transfers. Present session management technologies do not natively integrate three main features of XMPP: strong identities, presence information, and upfront federation between domains. Presence enables the similar kind of fluid communication that is noticeable from instant messaging. Entrusted identities considerably reduce the chances of spam.



    XMPP technologies use a decentralized client-server architecture related to the architecture used for the World Wide Web and the email network. In decentralized client-server architecture, client developers can focus on user experience, and server developers can focus on reliability and scalability. It is much simpler for organizations to manage than a purely peer-to-peer technology. It is a high availability system because the full system does not have a single point of failure, and the servers can implement important security plans such as channel encryption, user authentication, and prevention of address deceiving.


    As XMPP communications happen on a network, it needs an address. This address is known as a Jabber ID (JID). XMPP typically depends on the Domain Name System (DNS) to deliver the underlying structure for addressing, instead of using raw Internet Protocol (IP) addresses. Every Jabber ID contains a domain portion which maps typically to a fully qualified domain name (FQDN). The domain portion of a JID is case-insensitive for ASCII characters.

    Figure 1: XMPP Architecture


    For virtual identity on the network, a Jabber ID is chosen to create an account at XMPP service. It might be possible that Jabber ID is assigned automatically. Jabber ID looks similar to an email address. It can also be the same as email address, depending on the deployment policies. For example, Google Talk on the XMPP network looks the same as the Gmail addresses of users. The user portion of the JID is case insensitive.


    When anyone connects itheir client to an XMPP server, a resource identifier for that particular connection is assigned by the server or might be chosen by the user. This resource is used for routing traffic to that connection. It is independent of any other connection that is opened at that moment. The resource is added at the end of the user account address and enables query or exchange messages with a particular device that is associated with the specific account. The resource can be any string, and often the name of the computer, location, or the client software that has been used. The resource portion is case-sensitive.


    The main difference between email addresses and JabberIDs is that XMPP is fully internationalized. This signifies that XMPP domain names and usernames are not confined to the boring old ASCII character range, but can consist of practically any Unicode character.


    On the XMPP network itself, JabberIDs are endowed as raw addresses without a Uniform Resource Identifier (URI) scheme. This is related to the convention of telling someone to visit (instead of, or sending an email to the list (instead of However, there is an XMPP URI method that can be used to recognize JabberIDs as URIs, such as or XMPP:stanfordr@jabber. This URI scheme is defined in RFC 5122.



    XMPP is used for streaming XML. The XML Stream class conceptualizes away the problems of establishing a connection with a server and sending and receiving XML stanzas. A stanza is an extensive XML element that is a direct outcome of a root document element. Over the same socket, two streams are used for each communication direction. Both streams should be complete and valid XML documents after the connection has been closed.


    There are three types of stanzas:


    • Presence – This gives information associated with a user’s presence (status, online, offline, etc.).
    • Message – These are the actual messages sent between users.
    • IQ – This provides information based on queries, such as to update the user's profile, repossess a user’s information or get a user’s roster information, etc.


    Life Cycle of an XMPP Connection

    • Connection: To establish streams, the server-client must first establish a connection. SRV records are used in the case of XMPP. When a client wants to connect to a server or another server, it first inquires for the appropriate SRV record at the server’s domain. After record retrieval, the connection is established.
    • Creating streams: After connection establishment, the streams have to be opened from both sides to allow the exchange of elements, i.e., stanzas.
    • Authentication: XMPP authenticates clients using Simple Authentication and Security Layers (SASL) protocol; the client is bound to a resource once it is authenticated.
    • Disconnection: When a user logs out on their client, a presence stanza is sent to the server, stating to the server that the user is unavailable. So, the other users will get notified about the offline status. After this, the stream is terminated.


    XMPP community

    The XMPP developer community is incredibly diverse. XMPP applications development requires understanding how the XMPP developer community is structured.The XMPP community contains many participants, including:


    • Individual developers and open source projects
    • The XMPP Standards Foundation (XSF), which focuses on the standardization of the XMPP protocols
    • Service providers such as DreamHost, LiveJournal, Google, and GMX
    • Large software and hardware companies such as Cisco, Apple, Sun, and Nokia
    • Companies and universities that use XMPP services
    • Mobile devices consultancies that support specific codebases or offer XMPP expertise in particular domains


    The XMPP community is decentralized in the same way as the technology is decentralized and each project has its own website, repository, and communication channels. There is no single central location where all of these companies, projects, and other parties host their code or share their experience.


    Today XMPP is used for many applications like Group chat, Gaming, Geolocation, and Voice over IP (VoIP). Some of these are Jitsi, Adium, Psi (instant messaging client), Tkabber, Conversations, etc.