The Extensible Messaging and Presence Protocol (XMPP) is a network protocol that uses XML to exchange structured data between two or more network connected entities in near-real-time. XMPP was created to satisfy the IETFs guidelines for instant messaging and presence protocols (RFC 2779), but its purpose goes far beyond IM. It is also used as a message-oriented middleware, for machine-to-machine (M2M) communication and for the Internet of Things (IoT).
The lightweight XMPP core protocol provides users with
The extensible approach makes it possible to build custom protocols on top of XMPP core.
The core XMPP protocol is defined in RFC 6120 and is managed by the Internet Engineering Task Force (XMPP). The instant messaging extensions are defined in RFC 6121, and a third document (RFC 7622) defines the format of XMPP addresses, also called "Jabber Identifiers" (JIDs). Additional functionality is specified in the form of XMPP Extension Protocols (XEPs), which are created by the community and maintained by the XMPP Standards Foundation (XSF).
XMPP addresses, more commonly known as JIDs (Jabber Identifiers) are defined in RFC 7622 and act as addresses on the XMPP network. They look like an email address, but sometimes have an optional "resourcepart" at the end that identifies a particular client logged in as the account represented by the rest of the address (since XMPP may have multiple clients connected per account). An example of an XMPP address with the resourcepart (a client) xyz is:
[email protected]/xyz
XMPP allows for the full-duplex exchange of structured data and concurrent processing of requests between globally addressable clients and servers on the network. Unlike HTTP and the "Representational State Transfer" (REST) architecture widely deployed on the web, XMPP connections are stateful and concurrent, and an unlimited number of transactions may occur in the context of a single session. This architecture is sometimes refered too as "Availability for Concurrent Transactions" (ACT).
To faciliate routing across the network, all XMPP addresses are globally addressable. Like email, this is acomplished with DNS and a federated client/server architecture. Addresses are of the form localpart@domainpart/resourcepart where the localpart is optional and corresponds to a user of the network, the domainpar is required and corresponds to a server, and resourcepart is optional and refers to a specific connected client for that user (in XMPP users may be signed in from many different locations, eg. a phone and a laptop in the case of instant messaging, or many sensors using one account in the case of internet-of-things enabled devices). XMPP also provides facilities for discovering the presence (availability) of other addresses on the network.
XMPP connections are long lived TCP connections that transport XML streams from a client to a server (c2s) or from a server to a server (s2s). Having these sessions be long lived and stateful allow nodes in the network to transmit data at any time and have it routed or delivered immediately.
Streams form a direct link on the network between a client and a server or a server and a server. If a client wishes to communicate with a remote client on the network, they first send the information to their server which forms a server-to-server connection with the remote server which then delivers the information to its client.
Servers in the XMPP network route data, but also have a number of other responsibilities including maintaining session state, storing client data (chat history, files, messages sent when no client was online to receive them, contact lists, etc.). They are where most of the business logic of handling an XMPP connection lives. This allows clients to remain as "dumb" as possible (containing very little logic).
XMPP connections comprise two XML streams: one for ingress and one for egress. These streams are generally sent over the same TCP connection (although sometimes multiple connections may be used, especially for server-to-server connections) and share certain features for which negotiation is required (eg. authentication with SASL).