The purpose of this document is to specify the functionality of the existing SLC/PEP-II control software subsystem and applications. Not to be included here are any design related or implementation discussions. Also, in order to distinguish SLC features from NLC requirements, any discussion of anticipated NLC software should be limited to the last section of the document.

1. Message Service


This describes the functional requirements for the SLC Message Service. This is the common API by which almost all SLC software communicates. It has undergone several major enhancements since the initial implementation.
 

2. Purpose


A. What is the application for and why is it necessary?

Rather than an application, the message service is a crucial API and supporting routines used for almost all of the inter-task/process communication in the system. The initial emphasis was for communication over SLCNET between processes on the VAX and/or tasks on the micros. A later, separate implementation called Area Message Service (AMS) was added to provide similar functionality over TCP/IP for the new applications which were done using VME crates and the pSOS operating system or even (gasp!) PCs running DOS.

B. Who uses it?

With the exception of Kisnet, which was a special point-to-point network used just for Fast Feedback, all processes on VMS and tasks on other remote computers use one of the two message service implementations to exchange commands and data.
 

3. Operating Environment


The message service operates throughout the control system. This means that it must have an implementation on every node, regardless of hardware or operating system.
 

4. Functional Requirements


I'll start with some general requirements and then proceed to the specifics. I'll combine both the initial SLCNET based message service (SMS) and the later TCP/IP based Area Message Service (AMS) into one set of requirements. This means that some of these requirements may not be completely fulfilled by either implementation alone.

Destinations are defined locally, usually with an include file so there is no name service in either SLC implementation. Let's see what happens.
 

1. The message service must have a well-defined API so that it can be used in the same manner by any task on any node in the control system. I think that for AMS this is pretty much true. Less true for SMS.
2. The same API can access the destination task on the local node or anywhere on the network.  Not perfectly implemented in SMS.
3. Both synchronous and asynchronous messaging is supported. Ture for both.
4. Messages of arbitrary length can be sent or received on either the local node or any node on the network. SMS doesn't really meet this requirement but it tries. Becuase it relies on TCP/IP, AMS comes closer.
5. All error retries and connection maintenance (if any) are handled by the message service.
6. Messages can be sent to multiple nodes with a single call.
7. Message can contain arbitrarily structured data, ASCII or binary. Only the sender and receiver must agree on its format.


Now lets get down to the specifics of the API. I'll use generic functions e.g. SEND to incorporate both SMS and AMS functionality.  This these names may not correspond to any routine which presently exists in either SMS or AMS.
 

1. The INIT function performs all local message service initialization. When it completes successfully, the task can use all message service functions.
2. The SEND function synchronously transmits the message to each of the specified destinations. It does not return until the message has been successfully transmitted or an error has occurred.
3. The SEND_ASYNCH function returns as soon as the message is sent without waiting for a successful completion. The user can specify an action routine to handle the completion when it occurs or can later test a status to verify successful completion.
4. The SEND_ONE function synchronously sends a message to one or more destinations and waits for the expected reply(ies). It is synchronous and doesn't return to the caller until all replies are complete or a timeout has occurred.
5. The RECEIVE function is synchronous and waits for an incomming message for a specified time period which may be forever.
6. The RECEIVE_ASYNCH function allows the use to specify an action routine to handle incoming messages and/or a status which can be checked to see if messages have arrived.
5. Performance Requirements


Since this is a quasi-realtime system performance should be high on the list. Hard to know what to say here but I'll give it a shot.
 

1. Copying of message buffers should be kept to a minimum. Obvious performance hit here.
2. Minimal additional overhead should be added to the underlying network or mailbox system services.
6. Resource Dependencies


Managing connections and memory pool is a significant factor in implementing a message service.
 

7. Hindsight & Foresight [optional]


There we're several major 20-20 hindsight issues, which we wish we had done differently.
 

1. For the SMS implementation, communication between VMS processes was limited to a systems defined parameter for mailbox size.
2. The message service header must be inlcuded by each process/task using the service and the body of the message followed this header. Thus, any changes to the header meant recompiling most of the known universe.