Datasheet

The XMPP Network

7
Clients
The majority of XMPP entities are clients, which connect to XMPP servers via the client-to-server
protocol. Many of these entities are human-driven, traditional IM users, but there are also auto-
mated services running as bots.
Clients must authenticate to an XMPP server somewhere. The server routes all stanzas the client
sends to the appropriate destination. The server also manages several aspects of the clients’ sessions,
including their roster and their bare address, which you see more of shortly.
All of the applications in this book are written as client applications. This is typically the starting
point of most XMPP development. For applications without a user focus or with demanding needs,
it is often preferable to create a different kind of entity, such as a server component.
Components
Clients are not the only things that may connect to XMPP servers; most servers also support exter-
nal server components. These components augment the behavior of the server by adding some new
service. These components have their own identity and address within the server, but run externally
and communicate over a component protocol.
The component protocol (defined in XEP-0114) enables developers to create server extensions
in a server-agnostic way. Any component using the protocol can run on any server that speaks
the component protocol (assuming it doesn’t use some special feature specific to a particular
server). A multi-user chat service is a typical example of something that is often implemented as a
component.
Components also authenticate to the server, but this authentication is simpler than the full SASL
authentication for clients. Typically authentication is done with a simple password.
Each component becomes a separately addressable entity within the server and appears to the out-
side world as a sub-server. XMPP servers do not manage anything beyond basic stanza routing on
behalf of connected components. This allows great freedom to component developers to do things
exactly as they want, but places greater responsibility on them when they need functionality such as
rosters and presence management.
The server also allows a component to internally route or manage stanzas for itself. A component
can therefore create separately addressable pieces to be used as rooms, users, or whatever the devel-
oper requires. This is something that a client session cannot do and can be used to create really
elegant services.
Finally, because components do not have resources managed for them, services that operate with
many users or with a high amount of traffic can manage their own resources in a way that makes
sense for their purpose. Developers often create services as client bots, only to discover later that the
server’s roster management capabilities often do not scale well to thousands upon thousands of con-
tacts. Components can manage rosters, if they have them at all, in whichever way makes sense for
the task and scale required.
40718c01.indd 7 11/30/09 8:23:49 PM