Extensible Messaging and Presence Protocol (abbreviation XMPP, originally named Jabber) is an open communication protocol designed for instant messaging (IM), presence information, and contact list maintenance. Based on XML (Extensible Markup Language), it enables the near-real-time exchange of structured data between two or more network entities. Designed to be extensible, the protocol offers a multitude of applications beyond traditional IM in the broader realm of message-oriented middleware, including signalling for VoIP, video, file transfer, gaming and other uses. Unlike most commercial instant messaging protocols, XMPP is defined in an open standard in the application layer. The architecture of the XMPP network is similar to email; anyone can run their own XMPP server and there is no central master server. This federated open system approach allows users to interoperate with others on any server using a Jabber identifier (JID) user account, similar to an email address. XMPP implementations can be developed using any software license and many server, client, and library implementations are distributed as free and open-source software. Numerous freeware and commercial software implementations also exist. Originally developed by the open-source community, the protocols were formalized as an approved instant messaging standard in 2004 and have been continuously developed with new extensions and features. Various XMPP client software are available on both desktop and mobile platforms and devices – by 2003 the protocol was used by over ten million people worldwide on the network, according to the XMPP Standards Foundation.
Federated Instant Messaging Although the protocol has other uses, the primary application is Federated Instant Messaging, to deliver a standard Instant Messaging and Presence Protocol, outlined below. A client Alice ("alice@example.com") has a message for some other user, Beth ("beth@example.com"), and uses XMPP to convey this to the example.com server. If Beth is online, the server delivers the message instantly, otherwise it will be held for delivery later. If Beth is offline, this status is visible to Alice. If the message is for a user on another server, Charles ("charles@example.net"), then the example.com server connects using XMPP to pass the message to the example.net server. The message is then similarly delivered or held, and Alice is informed of the status. Following the initial message delivery, the end clients are in a "chat" and each party is subsequently informed of changes to the other's status.
Client-to-Server XMPP and Server-to-Server XMPP The XMPP client communicates with the server over a TLS-encrypted TCP stream on port 5222. XMPP servers communicate with each other over a TLS-encrypted TCP stream on port 5269.
Protocol characteristics
Decentralization
The XMPP network architecture is reminiscent of the Simple Mail Transfer Protocol (SMTP), a client–server model; clients do not talk directly to one another as it is decentralized – anyone can run a server. By design, there is no central authoritative server as there is with messaging services such as AIM, WLM, WhatsApp or Telegram. Some confusion often arises on this point as there is a public XMPP server being run at jabber.org, to which many users subscribe. However, anyone may run their own XMPP server on their own domain.
Addressing
Every user on the network has a unique XMPP address, called a Jabber ID (JID). The JID is structured like an email address with a username and a domain name (or IP address) for the server where that user resides, separated by an at sign (@) – for example, alice@example.com Here alice is the username and example.com the server with which the user is registered. Since a user may wish to log in from multiple locations, they may specify a resource. A resource identifies a particular client belonging to the user (for example home, work, or mobile). This may be included in the JID by appending a slash followed by the name of the resource. For example, the full JID of a user's mobile account could be username@example.com/mobile. Each resource may have specified a numerical value called priority. Messages simply sent to username@example.com will go to the client with highest priority, but those sent to username@example.com/mobile will go only to the mobile client. The highest priority is the one with largest numerical value. JIDs without a username part are also valid, and may be used for system messages and control of special features on the server. A resource remains optional for these JIDs as well. The means to route messages based on a logical endpoint identifier—the JID, instead of by an explicit IP address—presents opportunities to use XMPP as an overlay network implementation on top of different underlying networks.
XMPP via HTTP The original and "native" transport protocol for XMPP is Transmission Control Protocol (TCP), using open-ended XML streams over long-lived TCP connections. As an alternative to the TCP transport, the XMPP community has also developed an HTTP transport for web clients as well as users behind restricted firewalls. In the original specification, XMPP could use HTTP in two ways: polling and binding. The polling method, now deprecated, essentially implies messages stored on a server-side database are being fetched (and posted) regularly by an XMPP client by way of HTTP 'GET' and 'POST' requests. The binding method, implemented using Bidirectional-streams Over Synchronous HTTP (BOSH), allows servers to push messages to clients as soon as they are sent. This push model of notification is more efficient than polling, where many of the polls return no new data. XMPP also supports using WebSockets to communicate to a server. Because the client uses HTTP, most firewalls allow clients to fetch and post messages without any hindrances. Thus, in scenarios where the TCP port used by XMPP is blocked, a server can listen on the normal HTTP port and the traffic should pass without problems. Various websites let people sign into XMPP via a browser. Furthermore, there are open public servers that listen on standard http (port 80) and https (port 443) ports, and hence allow connections from behind most firewalls. However, the IANA-registered port for BOSH is actually 5280, not 80.
… excerpt ends here. Continue reading the full article.
