Global System Services Corporation (GSS) - The leading provider of email and messaging, directory services, and groupware consulting and professional services

Although the features of the user mail applications are the most obvious strength of cc:Mail as a system, it is actually the cc:Mail Router that makes the system adaptable and scalable. The cc:Mail Router is a remarkably robust and flexible message transport agent. The cc:Mail Router can transport message between post offices in several ways; send, receive and process updates to the cc:Mail Directory; propagate bulletin board messages across post offices; and schedule OS/2 command files or DOS batch files to automate routine tasks.

The cc:Mail Router is currently available only for the OS/2 and DOS operating systems. Command line parameters and usage for these two platforms are the same, except that the OS/2 version of the program is named ROUTER2.EXE while the DOS version is named ROUTER.EXE. The examples in this article will show the command line for the DOS version unless otherwise indicated.

This article introduces key cc:Mail Router concepts and walks you through some of the tasks associated with configuring and running one or more cc:Mail Routers. Before getting into how to use the cc:Mail Router, you’ll want to understand what the cc:Mail Router is and how it works. A little understanding can go a long way when you need to troubleshoot a problem.

The cc:Mail Router sends and receives messages both by moving them between cc:Mail post office files and by exchanging messages with other cc:Mail Routers or cc:Mail Mobile applications. In spite of the name "Router," the cc:Mail Router does not route network traffic. Network routers route network traffic at the network layer in the OSI model. The cc:Mail Router, however, is an application program that generally interfaces with the network at the application layer.

A PC can be configured for use with cc:Mail Router that support multiple LAN topologies. This is done by installing multiple network interface cards in the cc:Mail Router PC and loading the appropriate drivers on each card. Some documentation refers to this as a bridged LAN configuration. However, the cc:Mail Router does not function as a network bridge or router even when the cc:Mail Router PC is connected to disparate LANs.

Although the cc:Mail Router is an application in the OSI model, it can be configured to use network protocols to exchange messages with other cc:Mail Routers and cc:Mail Mobile applications. In other words, the cc:Mail Router accesses cc:Mail post office files like a user mail application but also has network-based data communications capabilities. In fact, the cc:Mail Router supports a variety of asynchronous serial communication and network-based data communications methods.

Supported network protocols include:

Overview of Call Lists and Connections

Each cc:Mail Router runs at a specific post office. An originating post office is the post office where a cc:Mail Router is running when it initiates a call or connection. An answering post office is a post office that accepts a call or connection. A call or connection is usually answered by a cc:Mail Router but for message transfer using file I/O, only one cc:Mail Router is necessary (see File I/O Message Transport below). When not making calls or connections to other post offices, the cc:Mail Router switches to "listen mode" in order to answer calls from other cc:Mail Routers or cc:Mail Mobile applications. There is no listen mode for the file the I/O message transport because only one cc:Mail Router is involved.

Outbound calls and connections are scheduled and prioritized in one or more Call Lists. Really there is only one list of post offices that are called but entries on the list are assigned to a list number. Call List entries with the same list number are said to comprise a Call List. The entries on each Call List consist of the names of post offices that are listed in the cc:Mail Directory and that have cc:Mail addresses.

Calls and connections can also be initiated manually by the cc:Mail Administrator. When a call or connection is initiated manually, it is referred to as an express call.

Post Office Addresses

In the cc:Mail Directory itself, the directory entries for post offices on the Call List contain a cc:Mail address specific to the message transport used. In other words, for outbound phone calls using a modem, the cc:Mail address of the post office called is a phone number in the cc:Mail directory of the originating post office. For outbound TCP/IP connections, the cc:Mail address of the post office called is the TCP/IP address of a cc:Mail Router at that post office. For outbound file I/O connections, the cc:Mail address of post office called is an OS/2 or DOS drive letter and path in the cc:Mail directory of the originating post office.

A post office address of the can also be blank or it can be the name of another post office. This will be important for cc:Mail message routing topologies.

Message routing is a store-and-forward process. When a message is sent to a user at another post office, it is queued up to go to that post office until a cc:Mail Router passes the message along. In the same way that each local user in a post office has a mailbox file containing a list of messages, or inbox, each post office that a cc:Mail Router calls or connects to has a mailbox file in the originating post office that containing a list of messages. User mailbox files are named USR????? in versions prior to Release 6 and ????????.USR in Release 6 and later.

Post offices that a cc:Mail Router connects to always have location status "P" in the cc:Mail Directory of the originating post office. A post office entry in the cc:Mail Directory of a given post office having a location status of "P" has a mailbox file, like that of a local user, in the directory where the post office files are stored. Functionally, the mailbox files associated with post offices are message queues. In the queue are messages slated to go to the post office whose queue they are in. When a local user sends a message to another local user, the user mail application of the sender writes the message directly into the mailbox of the recipient (instantaneous delivery). When a local user sends a message to a user at another post office, the user mail application of the sender writes the message into the mailbox associated with the recipient’s post office.

This has some useful implications. The first, strange as it sounds, is that you can log into a post office with a user mail application as another post office. In other words, you can specify the name of a post office as the user name when you log in. The password will be the administrative password for the current post office and not that of the post office specified as the user name. You can use this ability to return or delete messages in a queue, if necessary.

If you log in to a post office queue with a user mail application, be careful not to inadvertantly open any messages. Messages marked as read will not be sent by the cc:Mail Router.

In versions prior to Release 6, if you log in to a post office queue with the cc:Mail for Windows user mail application, a Message Log folder is automatically created and copies of messages sent to that post office will be retained.

Another implication is that you can use the cc:Mail Notify program to monitor post office queues. The cc:Mail Notify program will tell you how many messages are queued up and what the headings of the messaeges are. In the OS/2, DOS and MS Windows environments, the cc:Mail Notify program allows multiple mailboxes to be monitored. This means that you can use the cc:Mail Notfiy program to monitor multiple message queues.

Routing Relationships

There are two basic routing relationships between post offices, master-slave and peer-to-peer. A post office is said to be a routing master relative to another post office if its cc:Mail Router calls the other post office but not their reverse. In other words, if post office A always calls or connects to post office B, but post office B never calls or connects to post office A, then post office A is a routing master and post office B is a routing slave. Of course, a post office may be a routing master to some post offices and a routing slave to others at the same time. In the cc:Mail Directory of a slave post office, the cc:Mail address of the master post office is usually blank.

A post office is said to be a routing peer relative to another post office if both post offices have cc:Mail Routers that call or connect to the other post office. Of course, a post office can be a routing peer to some post offices and a routing slave or master to others at the same time.

Routing relationships and post office addresses combine to create routing topologies. A routing topology is the collection of message routes that are created by routing relationships and post office addresses in a given cc:Mail system. One of the main issues in designing a routing topology is the number of post offices a message must pass through to get from its source to its destination. This is sometimes called the number of hops.

Multiple cc:Mail Routers and Exchange Parameters

A cc:Mail post office may have no cc:Mail Routers, a single cc:Mail Router, or multiple cc:Mail Routers. Multiple cc:Mail Routers can use separate Call Lists or more than one cc:Mail Router can operate use the same Call List. When using from the same Call List, each cc:Mail Router is assigned a unique sublist number by specifying the Call List and sublist number on the cc:Mail Router program’s command line. For example, the command line parameter "LIST/2" specifies Call List 2, while the command line parameters "LIST/2.1" and "LIST/2.2" specify the first and second cc:Mail Routers using Call List 2. The sublist number is important because othersise messsages can be delivered more than once -- up to once by each cc:Mail Router using the same Call List.

Multiple Call List entries per post office ar allowed. However, you should not place multiple Call List entries for the same post office on different Call Lists if any of the conditions that trigger a call overlap. This would allow more than one cc:Mail Router to send the same message at the same time. Use sublist numbers instead to prevent duplicate messages. Sublist numbers do not work across Call Lists.

One of the main advantages of multiple cc:Mail Routers per Call List is the ability to have each cc:Mail Router process different types of messages in parallel. For example, one cc:Mail Router could process only messages marked urgent, while another could handle cc:Mail Directory updates and so on.

The cc:Mail Router provides three different message transports:

When a message transfer is initiated the cc:Mail Router is said to be placing a call. I’ll use the term call for serial communications but I’ll use the term connection for application-to-application network data communications. I’ll also use the term file I/O to describe access to a set of post office files through OSI model application-layer services. Although file I/O is a generic term, it is used here in the context of message transport mechanisms between cc:Mail post offices rather than referring to only one post office.

The terms Type I and Type II are sometimes used to describe cc:Mail Router communications. Type I refers to connections where only one cc:Mail Router is involved and is specific to the file I/O message transport. Type II refers to Router-to-Router communications, regardless of message transport.

File I/O Message Transport

The cc:Mail Router moves messages between post offices directly by accessing two sets of post office files at the same time. The cc:Mail Router reads messages from one set of post office files an writes them to another, deleting them from the message queue of the sending post office after they have been successfully written to the receiving post office. To do this the cc:Mail Router PC must have access to the post office directories on one or more LAN file servers. Typically, this means that the cc:Mail Router machine has a drive letter associated with each file server volume where a post office is stored and that it must have appropriate privilidges or access rights to read and write the post office files.

Although the file I/O message transport works over a network, it is not the same as application-to-application network data communications. The file I/O message transport is network independent -- it will work with any network where file access services are provided at the application layer in the OSI model. Figure 5.1 illustrates the file I/O message transport showing example cc:Mail Directory entries, Call List entries, cc:Mail addresses and drive mappings. In this configuration, no application-to-application network data communication takes place.

Figure 5.1: Master-Slave Message Routing using File I/O Message Transport (Type I connection)

Asynchronous Message Transport

The cc:Mail Router can exchange messages with other cc:Mail Routers and with cc:Mail Mobile applications through asynchronous serial communications. This means that the cc:Mail Router can use telephone modems and other serial communications using standard COM ports under the OS/2 and DOS operating systems.

Figure 5.2 shows this process along with the cc:Mail Directory entries, Call List entries, cc:Mail addresses and drive mappings for asynchronous communications using modems.

Figure 5.2: Peer-to-Peer Message Routing using Asynchronous Message Transport with Modems (Type II connection with modems)

©1996, 1997 by Global System Services Corporation (GSS) Portions of this material are ©1995 by Ron Herardian

DISSEMINATION, DISTRIBUTION OR COPY OF THIS INFORMATION IS STRICTLY PROHIBITED. NO PART OF THE INFORMATION CONTAINED HEREIN MAY BE REPRODUCED IN ANY FORM BY ANY ELECTRONIC OR MECHANICAL MEANS, INCLUDING PHOTOCOPYING, RECORDING, OR INFORMATION STORAGE AND RETRIEVAL, WITHOUT THE WRITTEN PERMISSION OF GLOBAL SYSTEM SERVICES CORPORATION.