NUEVAS PRÁCTICAS EN EL ARTE DE LEER

Chapter 3 ber world. Lois has an account on a Jabber server, and her Jabber Identifier (or JID) looks a lot like an e-mail address. Since Lois is an ABC employee, she registers the user name Lois with the Jabber server running at ABC.com, so her JID is [email protected]. Similarly, John has an account on his company (XYZ) IM server and his JID is [email protected].

Once Lois has logged in to the ABC.com server, she can send messages to her business associate John. Here is what happens when Lois starts the client on her laptop:

Lois sends a message addressed to [email protected].

The message is handled by the Jabber server at ABC.com.

The ABC.com server opens a connection to XYZ.net if one is not

already open.

Assuming that the IM administrators have not disabled server-to-

server communications between ABC.com and XYZ.net, Lois’s mes- sage is routed to the Jabber server at XYZ.net.

The server at XYZ.net sees that the message is addressed to a user

named “John” and delivers it to the Jabber client running on John’s PDA, where the message appears on screen for John.

There are a lot of pieces here: clients running on different operating sys- tems, multiple servers, a communication channel between the servers, and two business associates. Jabber handles everything but the last part. The process is illustrated in Figure 3.3.

3.2.1

Architectural Design

Figure 3.3 probably looks familiar, because it resembles the architecture of e-mail. Communications in Jabber are accomplished using a distributed network of servers, where each use a common protocol. Jabber clients con- nect to servers to receive messages from other Jabber users. They send messages to other users regardless of whether they reside on the same server or on any other server connected to the network. Jabber servers deliver messages in near real time. Real-time delivery is possible, because a Jabber server manages your presence status and knows when you are

offline or online. Jabber contacts can also see when you are online (if you

60 3.2 Jabber Protocol and XMPP

Presence knowledge is the key factor that enables IM to be instant. Jab- ber combines standard IM characteristics with some additional features to make Jabber unique. These features include:

1. Jabber uses a set of open, well-documented, easy-to-understand

protocols.

2. Jabber protocols are 100 percent XML, which enables structured,

intelligent messaging between human users and also between software applications.

3. Jabber uses addresses based on DNS and recognized URL

schemes, resulting in addresses of the same form as those used in e-mail (user@host).

4. Jabber technologies use a client/server architecture, not a direct

peer-to-peer architecture as some other messaging systems do.

5. Jabber supports a distributed network architecture.

6. Jabber has a modular server and simple client architecture.

Each of these key features is described in more detail in the following text. Open Protocols

Jabber technologies started in the open-source community with the jab-

berd server and clients for Microsoft Windows, MacOS, and Linux. As part

of its work, the original Jabber team defined an open protocol for streaming Figure 3.3

A Jabber IM session.

3.2 Jabber Protocol and XMPP 61

Chapter 3 XML over the Internet. This protocol continues to grow in depth and breadth. The depth comes mainly from work completed by the XMPP Working Group, the group that formalized the core XML streaming proto-

cols under the name Extensible Messaging and Presence Protocol. The breadth

comes mainly from work by the Jabber Software Foundation in defining extensions to the core protocols for a wide variety of features, including group chat, file transfer, service discovery, avatars, and much more. Because Jabber technologies all use an open protocol, anyone can implement the protocols, and they can use any manner of code license for their product. This has produced an explosion of Jabber software, including completely open-source servers and clients as well as proprietary commercial software. XML Data Format

XML is an integral part of Jabber technologies. Why? Because it makes them fundamentally extensible and able to express almost any structured data. When a client connects to a server, it opens a one-way XML stream from the client to the server, and the server responds with a one-way XML stream from the server to the client. Thus, each session involves two XML streams. All communication between the client and the server happens over these streams, in the form of small data snippets or “stanzas” of XML, such as the following message from Lois to John:

<message from=’[email protected]’ to=’[email protected]’> <body>Where are you, John?</body>

</message>

While many Jabber stanzas are that simple, Jabber’s XML format can also be extended through official XML namespaces (managed by the Jabber Software Foundation) and through custom namespaces needed for special- ized applications. This makes Jabber a powerful platform for transferring any structured data, including things like XML-RPC and SOAP procedure calls, RSS syndication feeds, and SVG graphics.

Standards-Based Addressing

Within the Jabber network, many different entities need to communicate with each other. These entities can represent servers, gateways, group chat rooms, a single Jabber user, and so on. Jabber IDs are used both externally and internally to express ownership or routing information. Key charac- teristics of Jabber IDs include the fact that they uniquely identify individ-

62 3.2 Jabber Protocol and XMPP

ual objects or entities for communicating instant messages and presence information.

They are easy for users to remember and are flexible enough to enable inclusion of other IM and presence schemes. Also, each Jabber Identifier (JID) contains a set of ordered elements. JIDs are formed of a node, domain, and resource in the following format:

[node]@domain[/resource]

The domain is the primary identifier. It represents the Jabber server to which the entity connects. Every usable Jabber domain should resolve to a fully qualified domain name. The Node Identifier is the secondary identi- fier. It represents the user. All nodes live within a specific domain. However, the Node Identifier is optional, and a specified domain (e.g., special.jab- ber.org) is considered to be a valid JID. The Resource Identifier is an optional third identifier. All resources belong to a node. In Jabber protocols, the Resource Identifier is used to identify specific parameters associated with the user, such as peripheral devices or locations. Resources enable a single user to maintain several simultaneous connections to the same Jabber server. Jabber users always connect to a server through a specific resource

and have an address of node@domain/resource (e.g., [email protected]/

stargate) while they are connected to the Jabber server. Because the resource is session specific, the user’s address can be communicated as node@domain (e.g., [email protected]), which is more familiar to people because it is of the same form as an e-mail addresses.

Client/Server Architecture

Jabber technologies use a client/server architecture. Some messaging sys- tems use a direct peer-to-peer architecture. Client/server architecture requires that all Jabber data sent from one client to another must traverse at least one Jabber server. A Jabber client connects to a Jabber server on a TCP socket over port 5222. Servers connect to each other on a TCP socket over port 5269. This connection is persistent for the life of the client session with the server. This means the client does not have to poll for messages as an e-mail client would do. Any message intended for delivery to the Jabber client is immediately pushed out to the client if he or she is connected. The server keeps track of presence information and, when it detects that a client has gone to offline status, it stores any messages sent to that client for deliv- ery when he or she next connects with the Jabber server.

3.2 Jabber Protocol and XMPP 63

Chapter 3 The client/server architecture is used in virtually all IM systems. IM cli- ents are installed on client machines, which then communicate with an IM server in the messaging provider’s infrastructure to locate other users and exchange messages. IM messages are sent first to an IM server and then from the IM server to the intended recipient, rather than directly from the initiating user’s computer to the recipient’s computer. The data is typically sent unencrypted (Figure 3.4).

Although most IM systems use client/server architectures to transmit their messages, some systems do use peer-to-peer messaging (P2P messag- ing). The chief advantage of P2P is that it can provide better security than a client/server architecture because both users are on the same local area net- work and because messages do not travel over the Internet. Peer-to-peer cli- ents contact the IM server to locate other clients. Once the client chat program has located its peer, it contacts the peer directly (Figure 3.5). Of course, if one user is located outside the corporate network, the peer-to- peer model will be just as insecure as the client/server model, because mes- sages sent between machines are exposed to potential eavesdroppers once the transmission hits the open Internet.

Figure 3.4 Client/Server IM.

64 3.2 Jabber Protocol and XMPP

Distributed Network

Jabber’s architecture is modeled after that of e-mail. Users connect to a home server, which will receive information on their behalf and transfer data to other servers on behalf of their home users. Thus, any domain can run a Jabber server. Each server functions independently and maintains its own user list. Any Jabber server can talk to any other Jabber server that is accessible via the Internet (if server-to-server communications are enabled). A particular user is associated with a specific server either through registra- tion with a service provider or administrative setup within an enterprise. Jabber addresses are of the same form as e-mail addresses. The result is a flexible, controllable network of servers, which can scale much higher than the monolithic, centralized services run by legacy IM vendors such as AOL, Microsoft, and Yahoo!

Modular Servers and Simple Clients

A Jabber server performs three primary tasks: handling client connections and communicating directly with Jabber clients; communicating with other Jabber servers; and coordinating the various components associated with the server itself. Jabber servers are designed to be modular. They are con- structed of specific code packages, which each handle a specific functional- ity, such as registration, authentication, presence, contact lists, offline message storage, and so on. Jabber servers can be extended with external Figure 3.5