The main feature of the ODSIMS is that it is distributed. By achieving this primary goal, the other goals are accomplished quite naturally. Therefore, it is instructive to immediately consider the proposed system's distributed networking model, illustrated in Fig. 1:
Fig.1 -- Network Model
This figure shows two clients and two servers. Each client connects to his own server and directly communicates only with his own server. The servers act as proxies for the clients by forwarding messages between their own clients and other servers.
Servers operate on well-known ports on fixed IP addresses. Client IP addresses, on the other hand, may vary, especially if their users are connecting through dial-up services. Clients remain connected to their servers for as long as they wish to have access to IM features. Clients can neither receive nor issue messages when they are not connected to their servers. However, servers can act on behalf of their clients for certain tasks even when the clients are off-line. (For example, a server can buffer incomng messages for off-line clients.) Clients locate each other by their IM addresses, which are very similar to email addresses, in that they include both a zone and a username within that zone.
Although ODSIMS clients and servers communicate with each other using reliable TCP connections, server-to-server communication is always accomplished by means of a reliable UDP datagram delivery protocol. This allows the servers to consume fewer system resources and also facilitates faster message dispatching, since there are no connections to set up. The drawback, of course, is that instant messages can be delivered out of order. This is easily addressed by the client, however, since each instant message is tagged with sequencing information.
Instant messages are wrapped in "envelops" by the sending clients before they are uploaded to servers for delivery. Depending on the envelop type, servers may or may not be able to decode the contents of these envelops, but they will always be able to forward them to the intended recipients. Delivered messages are unwrapped and decoded by the receiving clients.
Example
jack@army.org communicates with his colleague jill@navy.org in the following manner. First, Jack launches his client and directs it to connect to his own server at army.org. Jack's client then resolves the IP address for army.org and connects to the server at that address, beginning the authentication process. After Jack's server is satisfied that Jack is who he says he is, both Jack's client and server keep the connection alive but remain idle.
Finally, when Jack is ready to fire off his message, he types it into his client software and tells it to send. Jack's client packages up the message into a security envelope and uploads it to his server. The server relays the secure message to Jill's server. Jill's server transmits the message to Jill's client, which decodes the message and renders it on her screen. Jill responds in the same manner.
Of course, before sending his message, Jack may wish to verify that Jill is available, or, in other words, connected to her server. Jack's client is capable of making this determination. So Jack's client sends out a query through his own server, which in turn is forwarded to Jill's server, which in turn provides the answer, but only if Jill has indicated that she does not mind disclosing this information.