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
Jabber ID. 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 identifierthe JID, instead of by an explicit IP addresspresents 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.
Extensibility The
XMPP Standards Foundation or XSF (formerly the Jabber Software Foundation) is active in developing open XMPP extensions, so called
XEPs. However, extensions can also be defined by any individual, software project, or organization. To maintain interoperability, common extensions are managed by the XSF. XMPP applications beyond IM include:
chat rooms,
network management,
content syndication, collaboration tools,
file sharing, gaming, remote systems control and monitoring,
geolocation,
middleware and
cloud computing, VoIP, and identity services. Building on its capability to support discovery across local
network domains, XMPP is well-suited for
cloud computing where virtual machines, networks, and firewalls would otherwise present obstacles to alternative service discovery and presence-based solutions. Cloud computing and storage systems rely on various forms of communication over multiple levels, including not only messaging between systems to relay state but also the migration or distribution of larger objects, such as storage or virtual machines. Along with authentication and in-transit data protection, XMPP can be applied at a variety of levels and may prove ideal as an extensible middleware or
Message-oriented middleware (MOM) protocol.
Current limitations Since XML is text based, normal XMPP has a higher network overhead compared to purely binary solutions. This issue was being addressed by the experimental XEP-0322 Efficient XML Interchange (EXI) Format, where XML is serialized in an efficient binary manner, especially in schema-informed mode. This XEP is currently deferred. In-band binary data transfer is limited.
Binary data must be first
base64 encoded before it can be transmitted in-band. Therefore, any significant amount of binary data (e.g.,
file transfers) is best transmitted
out-of-band, using in-band messages to coordinate. In most cases this is dealt with by using an attachment to a message and the widely implemented XEP-0363 HTTP File Upload mechanism. Voice and Video chat can be done via the
Jingle XMPP Extension Protocol, XEP-0166. == Features ==