Message Flow

[Previous] [Next]

This section outlines the basic events that occur when a user sends an instant message to another user. The process depends upon whether the recipient is within the same domain as the sender or in a different domain.

Message Flow Within a Domain

First, let's assume that we have one IM routing server, Tucson, and one IM home server, Indianapolis. Furthermore, let's assume that David is sending an instant message to Sally. Figure 19-4 illustrates the steps involved in sending the message.

Figure 19-4. Message flow within a domain.

When David clicks Send, if the IM DNS information is not cached in David's memory, the instant messaging client contacts the DNS server to obtain the IP address of the server offering the IM service on the network. The DNS server looks up the IM routing server in the DNS tables, where it is specified with an _rvp SRV record for the RVP protocol. (For more information on how to set DNS up for Instant Messaging, see "Configuring DNS for Instant Messaging," later in this chapter.) The DNS server returns the IP address to David's instant messaging client software.

Next, David's instant messaging client software creates a TCP connection to the IM routing server—Tucson, in our example—over TCP port 80. The instant messaging client is assigned a port number above 1024.

After making the TCP connection, the instant messaging client sends a request to the IM routing server, essentially asking it to send an instant message to Sally. The IM routing server does not send the message directly but instead looks up Sally's user account in Active Directory, obtains the corresponding home server URL from her account properties, and returns that URL to David's instant messaging client software.

David's instant messaging client then makes another TCP connection over port 80 to Sally's home server and transmits the message, which uses a combination of HTTP and Extensible Markup Language (XML) to transport the message.

Finally, once the home server receives the message, it transmits the message immediately to Sally's instant messaging client software, which displays the message on the screen for her to read.

Message Flow Between Domains

When it comes to message flow between domains, IM really shines. To understand this process, let's use our previous example with one change—Sally and David are now in different domains at different companies. Figure 19-5 illustrates how a message would flow.

Figure 19-5. Message flow between domains.

When David sends a message to Sally, David's client software uses his Internet Explorer settings and sends the request to the proxy server, since the URL is a foreign domain. Finding the destination domain involves the same process on the Internet as finding a home page on a Web site.

At the receiving end, Sally's Internet Information Services (IIS) server receives the request because it is coming in over port 80. IIS looks at the URL and determines that its destination is the IM virtual directory (which exists on the IIS server but points to the routing server) that was set up when the IM routing server was installed. IIS forwards the request to the virtual directory, which in turn routes the message to the routing server because of the virtual directory assigned to the routing server.

Once the routing server receives the request, it would normally want to send the home server URL back to the client, but in this case David is in a different domain on a different network across the Internet. Sending the home server URL back to David is therefore impractical for a host of reasons, not the least of which is that it would consume too much time. Instead, the routing server reverse-proxies the request to the home server, which forwards the message to Sally's instant messaging client software.