Instant Messaging with Jabber

Chris Josephes

Instant messaging, unlike email, is designed to facilitate immediate communication. Client programs maintain a connection to the server, so the chances of messages being spooled on an intermediary server is unlikely. Most email environments consider message delivery within five days as an acceptable timeframe (given the possibility of failures on intermediary servers), and even when the message is finally delivered, there is no expected timeframe as to when the message will actually be read. Instant messaging is designed to only spool the message if the recipient is not connected to the server, and most client programs immediately alert the user when incoming messages arrive.

Instant messaging (IM) systems also include presence notification. When users log on to their instant messaging servers, the servers immediately update the online status of the users. This can help users determine whether message recipients will be able to quickly respond. Users can also manually set their availability status and provide profile information in a user directory for other users to view.

Addtionally, instant messaging applications usually use a chat-window interface for communication between users. Once a communication is started between two people, there is no need to issue reply commands or to re-enter the address of the other user. One window or screen contains a running transcript of a conversation between users.

In the corporate environment, the biggest benefit of instant messaging is response time. A manager can communicate in real time with his employees, find out whether business associates are reachable, organize contacts into groups, and alert other users of his own availability. It is best suited to quick running conversations that are relatively short, but would involve multiple messages going back and forth if done by traditional email.

The most popular instant messaging systems may be better described as online services that are offered to customers for free or for a low monthly fee. Using the instant messaging services of an outside provider is like moving your internal email systems to Hotmail. Most corporations aren't comfortable trusting their instant messaging needs to an outside service for several reasons including:

• Security -- All IM traffic between employees would go outside the corporate Internet connection to a central IM server and would probably all be in plain text. No one likes the idea of risking the exposure of company communications or files to possible packet sniffers. Furthermore, with proprietary instant messaging services, you may not be immediately aware of any security flaws the application may have.
• No administration control -- If your provider's IM servers go down, then you are relying on their administration policies and procedures, in addition to their terms of service.
• Interoperability -- Instant messaging between different systems is clunky at best, and some of the systems even try to ensure that outside providers can't access their systems.
• Namespace control -- Because most of the major providers claim more than a million users, it would be impossible to implement a consistent user-naming scheme. For example, for the user "John Adams", the userid "jadams" is already taken, and so is "jadams1", and you would have to repeat the process until you reach "jadams73".
• Client availability -- Some users run Windows, some run Mac OS X, and some run UNIX. The chosen system would need to support all platforms.
• User Privacy -- With buddy list searching, you risk exposing your employee names in a public database any user could scan, and with no namespace control, your users could expose internal data.

• Provider Stability -- Will your chosen instant messaging provider be in business a year from now?

Given these considerations, an internal instant messaging server would be ideal. It should allow corporate employee to administer, control the user accounts, keep all local traffic to the internal network, and handle the different clients in the corporate environment. Additionally, the system should ideally be free or at least inexpensive.

One platform that meets these requirements for instant messaging is Jabber. Jabber is an open-source system that provides what users expect in an instant messaging environment: messaging, presence notification, user rosters, and ease of use. It also addresses security, privacy, and central management issues. Jabber has an open-source server available for UNIX, and several clients for a variety of platforms including Windows, UNIX, Mac, and Java. Programming libraries for Jabber are available in C++, Java, and Perl, so you can create custom software that can incorporate Jabber features.

The principle of Jabber's design is to function as an XML stream routing System and instant messaging happened to be the first major application of its use. Because the protocol is based on XML, it can be easily extended to add more features as necessary.

How Jabber Works

When users set up accounts on a Jabber server, their full Jabber Identifier (or JID) is the handle they have chosen tied to the host FQDN (just like email addresses). When user J. Adams signs onto the server, his JID could be jadams@chat.example.com. Incoming messages to "jadams" are addressed to that JID, and outgoing messages use the JID as the "from" address.

A JID also contains a resource identifier at the end, such as jadams@chat.example.com/laptop. This way, J. Adams can be logged onto the server multiple times and the server will know which client session to route the message to. The resource identifier can be anything the users want it to be. Users usually set it to a string that identifies their computers or what client programs they are using. Most user clients are smart enough to automatically append the correct resource to a JID, so end users don't need to keep track of them.

End users can also communicate with other remote Jabber users through server-to-server communication. If jadams@chat.example.com, needs to communicate with bjones@chat.demo.com, the messages are routed through the two servers.

Another aspect of server-to-server communication involves the gateway abilities of Jabber. By compiling additional transport libraries, the Jabber server can act as a gateway to other IM systems, such as AOL, Yahoo, MSN, or even an IRC server. The local Jabber server passes on the sign-on data to the remote service and tunnels traffic from the user client to the outside server.

Communication Protocol

Almost everything Jabber does involves an XML stream or file. When a Jabber client sends a message to the server, the contents of the transmission look something like this:

<message to="bjones@chat.demo.com" from="jadams@chat.example.com">
<subject>Chip Pricing</subject>
<body>
Can you send me bulk pricing information on the Motorola MVIP302?
</body>
</message>

The protocol has three top-level XML elements: <message> for communication between two JIDs, <presence> for the exchange of availability information, and <iq> for structured information exchanges that don't involve presence or messages (such as authentication).

Jabber clients connect to the server using TCP port 5222. If you do not have a Jabber client available, it is possible to connect to the port using the telnet command and sending an XML stream manually.

Installing Jabber

The latest version of the Jabber server is 1.4.1, which can be downloaded from http://www.jabber.org. Before you download it, be sure the following is installed on your system:

1. GNU make

2. The GNU Pthreads Library

3. The OpenSSL Library (if SSL encryption is desired)

The configuration and build of Jabber is relatively straightforward. Run configure, then run gmake, and the system is ready.

When you build Jabber, keep your source directory intact. There are always new shared libraries being created for Jabber, such as gateway transports or authentication mechanisms. When you build additional shared modules for your Jabber server, the Makefile usually wants to read the platform-settings file that contains the settings information on how your Jabber server was compiled.

The installation of the Jabber server may be different from other software packages you have worked with before. There is no gmake install process, and the documentation says that Jabber can simply run from the directory in which it was compiled.

In reality, the Jabber server expects to run from the directory it was compiled in because that directory gets passed as a macro to the C compiler. When Jabber works with relative file paths, it uses the compilation directory as a base path, even if the jabberd executable is moved after compilation.

If you prefer to keep your source code and running software directories separate, you can do one of the following:

1. Edit the configure script, and change JHOME='pwd' to JHOME='/opt/jabber (or the final destination you choose),

or

2. Run jabberd with the -H /opt/jabber command-line option.

When you finish the build process, you will have one jabberd executable, and five shared modules (dialback.so, dnsrv.so, jsm.so, pthsock_client.so, and xdb_file.so).

An installed Jabber server will need a directory structure:

$ ls -lF /opt/jabber

dr-xr-x---  2 jabber  jabber  512 Sep 23 15:37 bin/
dr-xr-x---  3 jabber  jabber  512 Sep 23 11:42 etc/
dr-xr-x---  2 jabber  jabber  512 Sep 23 11:16 libexec/
drwxr-x---  2 jabber  jabber  512 Sep 23 11:42 logs/
drwxr-x---  2 jabber  jabber  512 Sep 30 07:53 run/
drwxr-x---  4 jabber  jabber  512 Sep 23 11:37 spool/

bin/        jabberd binary,
etc/        config file(s), SSL keyfile(s)
libexec/    shared libraries
run/        pidfile
spool/      server and user data files

If you later decide to compile new shared libraries (such as the conferencing module, or the Yahoo transport), build the library in your source directory, copy the shared library file to your server directory, and make any necessary changes to your configuration file.

DNS Setup

A simple Jabber server running basic client-server chatting will require a host entry set up in DNS. A single A record like chat.example.com or jabber.example.com will work.

Additional services may require additional A records, or CNAME records that point back to the same host. Some Jabber transports or modules are given a different hostname (such as msn.example.com for the MSN gateway transport, or conference.example.com for the conferencing module). This way, the server knows which module needs to handle the incoming XML stream. The Jabber protocol is similar to HTTP/1.1 because the server looks at the hostname passed within the data itself, and not necessarily the destination IP of the socket connection.

Configuration

Jabber uses a configuration file in XML format (see Listing 1). A sample configuration file is included with the server distribution. Most administrators use this file as a template and edit it to suit their needs.

The root node of the file is the <jabber> element, which contains all other nodes in the configuration. Underneath <jabber> are the <service>, <io>, <xdb>, <log>, and <pidfile> elements. The example XML file with this article includes an overview of each section of the file, and what most of the XML tags are responsible for configuring.

The most common error in the jabber configuration file is invalid XML markup. If the server fails to properly start up, and the error message is non-specific, try running the server in debug mode with the -D flag. If that doesn't provide enough information, run the config file through an XML parser.

Administration

Most Jabber administration involves the setup of user accounts or services running on the server. All of these tasks can be done by hand, or in some cases, can be performed from a Jabber client. The configuration file lets you define which JIDs belong to administrators so you can receive administration notifications and send special messages to special internal JIDs.

Startup/Shutdown

A simple startup/shutdown script must be written and placed in the appropriate startup directory for the system. You can restart the server by sending the HUP signal to the jabberd process, but there are two drawbacks (as of version 1.4.1):

1. All users are logged off as the system restarts.

2. If the pidfile from the previous run still exists, jabberd will complain and shut down immediately. The file must be removed before sending the HUP signal.

The only real need to restart the server occurs when you make a change in the config file or rotate any logfiles the process writes to. Depending on your traffic levels, you may be able to get by with a really long log rotation period (one week or more).

Spool File Modification

Local users on the server have an XML-formatted file containing their client settings and roster information. Under the spool/ directory is a directory for each Jabber server (named by the FQDN defined in the configuration file), and then each user information file. Other services (e.g., like the Jabber User Directory) may create other directories under spool/.

When Jabber needs to read a file, it keeps the data in memory, so changes you make to a file won't be read until the server is restarted. If you don't want to restart the server, the alternative is to put a <timeout></timeout> element under the <xdb_file> tag. The timeout element contains a single integer that refers to the number of seconds the server waits before it re-reads a file in the spool/ directory. A timeout value of 0 means the server will never cache the data.

Sending Server-Wide Messages

There are four special JIDs an administrator can send a message to:

[hostname]/announce/motd -- Announce the message of the day.

[hostname]/announce/motd/update -- Update the MOTD, and only send the update to users that haven't seen it.

[hostname]/announce/motd/delete -- Delete the MOTD.

[hostname]/announce/online -- Send to all current local online users.

A Jabber administer of chat.example.com would address the message to chat.example.com/announce/online to communicate with all online users. Some Jabber clients won't allow a message recipient that doesn't contain a "[user]@" in the JID. In that case, you must use a client that will let you send raw XML streams (such as WinJab), or develop a program that will send the XML for you.

Jabber as an Admin Notification Tool

Most systems or network administrators have set up their environments so they are automatically notified by email or pager when important system events occur, such as when snmp traps are encountered or when remote systems are no longer responsive. Depending on the seriousness of the notification, Jabber may be better than email for relaying important information. When programs such as Swatch send out an email message, they usually pipe their standard output to Sendmail or Qmail. Thus, the MTA is responsible for delivery of what could be a very important notification. If the mail spool of that MTA is already heavily loaded, or if the delivery of the message fails due to the misconfiguration of another machine, the entire notification process fails.

One alternative is to create a Jabber client program that can send the message. Listing 2 is a Perl script that uses the Net::Jabber modules to read the standard input and send a message to the JID specified on the command line. It connects to the defined Jabber server using an account set up explicitly for this program. It can be used to send a quick Jabber message from the command line, or it can be modified to be used in conjunction with the pipe option in the swatch configuration file.

You can use this example to create even more complex clients, such as a bot capable of receiving messages from users, or a program that sends out mass broadcasts to users listed in its internal roster. For more information, read the perldocs included with the Net::Jabber modules.

Additional Resources

The Jabber user community is continually growing. Jabber Inc. is busy forming partnerships for their commercial server, and there is a large group of open-source contributors volunteering their time to creating clients, documenting the protocol, and developing the product.

The best resource for Jabber information is http://www.jabber.org, which contains information on the server setup, the Jabber protocol, and a CVS repository for the server and transport code. The Web site http://www.jabbercentral.com is an advocacy site, listing the latest news regarding Jabber and a list of user client programs. The Jabber Inc. Web site is at http://www.jabber.com.

There is also a mailing list for Jabber administration at jadmin@jabber.org. Archives of the list can be found at http://mailman.jabber.org/listinfo/jadmin. If your Jabber server is working properly, you can log into the jdev conference room on the server conference.jabber.org.

Conclusion

It may be early to speculate on the future of instant messaging, but sooner or later large enterprises are going to have to decide how they will bring this service to their users. In the past, the only alternatives were internal groupware applications or the giant public IM services offered by ISPs. Jabber is currently the only solution that offers the advantages of an internal and external system. Another benefit is that it's an open protocol that has the backing of a corporation working to sell Jabber solutions to large companies.

Some administrators reading this probably remember a time when they had to deal with closed proprietary email environments. Jabber, however, provides a system that has both the potential to become a major standard in IM protocols, and has the backing of a large existing user base.

Chris Josephes is currently self-employed as a systems engineer in Minneapolis, Minnesota. He can be reached at: cpj1@visi.com.