CHAPTER 1 INTRODUCTION ABSTRACT An introduction to and overview of the AMI network messaging system is presented. Groundwork is laid via comparison of AMINMS with other common networking/messaging systems, in- cluding DECNET. 1.1 GETTING STARTED The hardest part of describing any serious piece of software is where to begin. With software, perhaps more than any similar (and are there similar) undertaking, one almost has to pick a spot, and go around at least once, before things start to make sense. Building a barn is much easier: you start by describing the dimensions, then the foundation, frame, and so on. The gross functionality of the system described here can be stated fairly easily: "Provide a mechanism whereby tasks running on RSX or VMS systems may send messages to other tasks running on the same or different network nodes." Well, that's nice, but, like all one-liners, leaves much to the imagination. So, lets start by characterizing and qualifying the above statement a bit. 1.2 MESSAGES A message consists of several pieces of information. A good analogy is that of the postal letter. A letter consists of destination name and address, return address, postage, the envelope, and finally whatever the sender put in the en- velope. A message contains the same information (except for the stamp!), but arranged somewhat differently. The INTRODUCTION Page 1-2 envelope is replaced by the MESSAGE HEADER. This is a record consisting of several fields which identify the sender, recipient, and provide control information, plus describe the size of the TEXT. The Text corresponds to the contents of the letter, and is a copy of an arbitrary chunk of memory. Like the postman, the message system is only concerned with moving the text (the letter) from one place to another. Neither cares what is in the letter, only how big (heavy) it is, and where it is going. So, we will talk about MESSAGES and TEXTs. The text is the information which the sending task want's the receiver to have. The rest (the Header) is overhead required to get the text to it's destination. A (not the only) Pascal record definition for a MESSAGE is: TYPE Message = RECORD Hdr: Msg_header; { a sub-record we haven't defined yet } Len: 0..MAX_LEN; { an RSX, 16-bit, integer } Text: Array [1..Len] of byte; end; You will note that this is not quite a legal Pascal definition, as the Text field ) is defined in terms of the Len field. However, it does convey the idea of an arbitrary chunk of 'text' (anything, really), associated with a byte count and a header. Another point is that, in a rigorous record definition, the Len field will be part of the header. We have also not defined the constant MAXLEN yet. It's exact limit will be defined in a later chapter. For now, assume that 500 bytes is the longest allowable text field. 1.2.1 Message Descriptors Because many record definitions would be required to describe all pos- sible messages (roughly 500), it is also convenient to define an en- tity called a MESSAGE DESCRIPTOR. This is nothing more than a small record: TYPE Message_Descriptor = RECORD msg_len: 0..max_len+hdr_len; msg_adr: Address; end; This is a much more convenient way to describe our arbitrary messages, because one record suffices to describe all possible messages. Note that the header has disappeared! This is because the message system views the message record as just a chunk of bytes starting at some ad- dress. The message descriptor defines the entire message - header and text - as one entity. The header fields must of course still be in there, or strange and probably unfriendly things will happen to the message! INTRODUCTION Page 1-3 1.2.2 Message Contents So far, nothing has been said about the contents of the message text field. This is because the messaging system doesn't CARE what is in there. So, it imposes no restrictions on the content of a message text. Like a postman, the messaging system does not know or care what is in a letter, only that the address is legitimate. ( The message system is not concerned with getting the postage right.) In summary, then, a MESSAGE consists of a HEADER (including a byte count ) and a text field, which must be less than about 500 bytes. A MESSAGE DESCRIPTOR consists of a different byte count, plus the ad- dress of the entire message. We don't care what is in the text frame, only about it's size. A MESSAGE HEADER consists of several fields which identify the sender and recipient of the message. 1.3 TASKS Letters are passed between people (occasionally between a computer and a person, but that's another can of worms). Messages are passed between tasks. Simply put, a TASK is a single program which is known to the system upon which it is running. Under RSX, the program is called a "task", and is known to the system by being INSTALLED. In VMS, a known program is called a PROCESS (there may be sub-processes or detached processes, but all are processes). However, the process need not be installed to be known. In fact, under VMS, we really identify a potential sender or reciever of a message by a Mailbox name. More on this later. For now, suffice it to say that messages are exchanged between programs. The term 'task' will refer to either an RSX program or the VMS analogue. 1.4 ROUTERS A router is, in the messaging system, a task which accepts messages from other tasks on the local node, and forwards them to a cooperating router task on a different node. The cooperating router (called the destination router) then forwards the message to a task (the destina- tion task) on that node. Although we use the term router, such a task might also be recognized as a "message server". In short, the sending task gives its' message to the router, who (like a postman) passes it to another router, who delivers it to the final addressee. Because the router is on the same node as the sender, it is much easier for the sender to talk to him than to the addressee. NOTE For performance reasons, the messaging system also sup- ports direct message passing between tasks on the same node. This is done transparently to the task, in all but the lowest subroutine levels. INTRODUCTION Page 1-4 There are many reasons for employing routers in a RSX/VMS network. While it is certainly possible for two tasks to set up various direct communications paths, doing so across two nodes involves a consider- able amount of overhead. The programs (and programmers) need a fair amount of knowlege of network (DECNET here) mechanics. At run time, the programs also incur relatively large overhead in establishing net- work links. The system would suffer from the need to maintain large numbers of links, and their associated data structures. Even in a network environment, most traffic will be between tasks on the same node. Using a DECNET link between two tasks on the same node is pos- sible, but is certainly the long way around, and is horribly ineffi- cient relative to other available messaging facilities. Even passing a message through a router is a waste of resources, which is why the system supports direct links. However, SOME traffic is likely to in- volve other nodes. By using a router, all traffic (from the tasks' point of view) is on the same node. This allows the task to use one function to talk to any task - local or remote. It would seem that involving two additional tasks (the routers) in a cross-node message would incur large performance penalties. However, as you will see, in many cases, the performance will actually be much better through a router than via direct network connections. This is especially true when relatively low volumes of data must be exchanged between rela- tively large numbers of tasks. A pair of tasks which merely want to pump high-volume data between themselves will do better to establish a dedicated link - and should do so. In the AMI message system defini- tion, only two routers will be involved in any message - that is, each router talks to all the other routers. This scheme is designed for, and will only work well on, small networks (perhaps a half-dozen nodes) which have physical links between all nodes - typically ETHERNET. A router can also handle the complexities of talking between systems - RSX and VMS in this case. Actually, very little translation is required. By inserting routers between VMS and RSX tasks, each task can talk it's own native style, which both simplifies the coding, and improves the efficiency of VMS-VMS or RSX-RSX messag- ing. A Router, then, is a task which accepts messages from tasks on it's local node, and from other routers via the network, and forwards them. The router exists to simplify application tasks, reduce network overhead, and provide some minimal translation between systems.