Table of Contents Previous Chapter 42 The SDT PostMaster

42 The SDT PostMaster

This chapter is a reference to the communication mechanism in SDT, the PostMaster. The functionality of the PostMaster makes it possible to integrate applications by using a well-defined means of communication.

Introduction to the PostMaster

---------------------------------------------------------------------
Caution!                                                               
The SDT PostMaster was originally designed and implemented for         
integrating tools in the SDT environment. Our experience is that the   
PostMaster is also suitable for integrating external tools and appli   
cations with SDT applications; one application area is for instance    
quick prototyping.                                                     
However, Telelogic does not support using the PostMaster as a com      
munication mechanism between real-time applications, in a run-         
time environment.                                                      
---------------------------------------------------------------------
The PostMaster is the mechanism used for communication between the different tools in SDT. A C program generated by SDT can also take advantage of this communication mechanism. It can communicate with any application connected to the PostMaster that send messages according to a defined format. This makes it possible for an SDT simulator to communicate with, for instance, a User Interface process generated by
TeleUSE. The PostMaster also provides the basic means for the Open SDT concept, see chapter 43, The SDT Public Interface.

The PostMaster provides the following functionality:

The PostMaster is a message passing service based on a selective broadcasting mechanism. It will distribute a copy of each message it receives to the tools subscribing to that type of message. By this, the PostMaster provides an integration mechanism between tools without the hard coupling between them that follows from conventional two part communication mechanisms.

Figure 562 illustrates some of the PostMaster concepts. The PostMaster maintains a list of which messages each tool subscribes to. Each tool has a PostMaster part for sending and receiving messages. In the figure, tool F broadcasts a message, i.e. the message is sent to the PostMaster. The subscription lists of tool A and C (but not the lists of B and F) contains the message type. Accordingly the PostMaster broadcasts the message to tool A and C.

Figure 562 : Example of a PostMaster broadcast. 
-----
(fig)  
       
-----
The PostMaster configuration is a file that informs the PostMaster about what tools and messages exist in the current context, i.e. it contains the message subscription lists. To include new tools or add new messages, the configuration must be edited.

For detailed information on the configuration, see "The PostMaster Configuration" on page 2485.

PostMaster Reference

This section describes the external interface to the PostMaster, including messages to send and their format, contents of the configuration, and functions to call.

Limitations in the PostMaster

This section only applies to installations on platforms which have limited socket buffers. The only platform with unlimited socket buffer sizes is SUN/SOLARIS.

For each application a UNIX socket is created. The usable size of this socket is implementation dependent. On platforms where this size is limited, the PostMaster maintains internal queues to overcome this problem. However, under exceptional circumstances, even these queues may be exhausted. To avoid this problem an application should always be prepared to consume its input from the PostMaster, or, if that is not possible, frequently check for incoming messages.

--------------------------------------------------------------------
Note:                                                                 
In order to promote a high throughput and avoiding buffer overflow,   
it is therefore strongly recommended that the PostMaster messages     
are consumed as soon as they are available. If an overflow occurs,    
the result is unpredictable.                                          
--------------------------------------------------------------------

PostMaster Messages

The PostMaster configuration defines a large number of messages that can be utilized in an SDT system. A broad range of these messages are public, that is, they can be used externally. A description of these are found in chapter 43, The SDT Public Interface.

All messages contain information about the identity of the sender, the time it was sent, the message type, and the size of an optional data part.

The optional data part can be seen as parameters to the message and is not interpreted by the PostMaster.

-------------------------------------------------------------------------
Note:                                                                      
It is the responsibility of the tools using the PostMaster to define the   
format of the data part and to interpret it correctly.                     
-------------------------------------------------------------------------

The PostMaster Configuration

The PostMaster can be configured either statically at start up or dynamically during runtime. When a dynamic configuration is performed, the SDT services Add Tool or Add Tool Subscription is used. The PostMaster is configured statically using the PostMaster configuration file(s)

The PostMaster configuration file(s) informs the PostMaster about what tools and messages exist in the current context. These files are often referred to as simply the configuration.

At startup the postmaster reads an environment variable POSTPATH which is a colon `:' separated list of directories. In these directories, the PostMaster searches for configuration files.

Such files should be named post.cfd and are read by the PostMaster whenever it is invoked, for instance when SDT is started.

It is not possible to use C preprocessor statements or symbols in the configuration file.

------------------------------------------------------------------
Caution!                                                            
The file post.cfd residing in $sdtbin that defines the existing     
tools in SDT must not be edited; otherwise unpredictable behavior   
may occur.                                                          
------------------------------------------------------------------
It is possible to have local configurations which extends the standard postmaster configuration set up by SDT, by simply defining the POSTPATH variable with a directory holding the extended configuration.

File Contents and Syntax

The configuration is a list of tool identities. Each tool identity is bound to an executable, a subscription list of messages and optionally a limit of instances of that tool. Each tool in the file is described in the following way:

Tool <tool number>:<executable>:<instance limit>
<message number>;
<message number>;
...

Description

Adding Tools and Messages

To include new tools or add new messages, the configuration file must be edited. However, the tools and subscription lists existing in the original configuration must not be changed.

To include a new tool, follow the steps below. Note that it is not required to include a new tool in the configuration if it only serves as an SDL environment that does not need to be started from other tools by using the Start service.

  1. Select a tool number not conflicting with the ones already existing in the configuration, preferably a number greater than 100000 and divisible by 1000.
  2. Make a new tool description in the configuration, using the syntax described above.
  3. Define a new SET_ symbol in the file sdt.h so that the tool number can be easily accessed in the code.
Example 254   
#define SET_MYTOOL   110000
  
To add a new message, follow these steps:

  1. Decide upon a tool that the new message "belongs to" or "is defined by," which should not be one of the pre-defined tools in the original configuration.
  2. Define a new SE symbol in the file sdt.h as the tool symbol plus an ordinal number, not conflicting with any other message symbol.
Example 255   
#define SEMYMESSAGE   SP_MESSAGE(SET_MYTOOL+1)
  
  1. Use the numeric value of the message symbol when adding the new message to a subscription list in the configuration.
Example 256   
50000+1;
  

Environment variables

The PostMaster recognizes a number of environment variables setting the context in which the PostMaster is to operate. They are read when the PostMaster starts.

PostMaster Environment Variables

The following environment variables are recognized by the PostMaster:

PostMaster Application Library Environment Variables

The following environment variables are recognized by the PostMaster application library:

If only one PostMaster is active, the application library automatically finds the PostMaster.

If more than one PostMaster is running and this environment variable is not set, a connection is made to the PostMaster instance having the highest process id value.

Functional Interface

Communication with the PostMaster is based on a small set of fundamental functions:

--------------------------------------------------------
SPInit         -- initialization                          
SPExit         -- termination                             
SPBroadcast    -- output message, broadcasted             
SPSendToTool   -- output message, sent to a certain tool  
SPSendToPid    -- output message, sent to a certain pid   
SPRead         -- input message                           
SP             -- translate a symbolic message to an id   
SPErrorString  -- Error string conversion                 
--------------------------------------------------------
Every function returns a value denoting success or failure of the associated operation.

Calling Conventions

The PostMaster functions should be called in the following ways from the external tool:

Variables

The following variables are defined.

extern INT16 sperrno;
extern INT16 spPortNO;
sperrno contains an error code when a call to a PostMaster function failed. The error codes are defined in sdt.h and should be self-explanatory.

spPortNO contains a descriptor to the port where incoming messages from the PostMaster are found. The state of the variable prior to the call of SPInit is undefined.

These variables are found in the file post.h.

Error Codes

When a function returns SPERROR which indicates an error or an not expected result of the function. In this case sperrno is set to one of the following values.

---------------------------------------------------------------
Error Code          Explanation                                  
---------------------------------------------------------------
SPNOSESSION         The function SPInit has not been called      
                    successfully                                 
SPALREADYCONNECTED  When calling SPInit more than once           
                    without disconnecting                        
SPNOPOSTMASTER      No postmaster could be found when trying     
                    to connect                                   
SPNOCHANNEL         The contact with the postmaster is lost.     
SPNOMESSAGE         No message available when trying to read     
                    by polling or after a timeout.               
SPTIMEDOUT          The connection to the PostMaster timed       
                    out.                                         
SPNOSUCHPID         Sending to a Pid with a non positive value   
                    (<=0)                                     
SPNOMEMORY          Cannot allocate anymore dynamic mem          
                    ory (rare)                                   
SPTOOLNOTFOUND      When sending to a tool, this tool is not     
                    found in postmaster configuration list       
SPINVALIDMESSAGE    Sending a message with a NULL parame         
                    ter but specifying the length greater than   
                    0.                                           
SPBADMESSAGE        A not supported message was to be sent.      
---------------------------------------------------------------

Functional Description

The available PostMaster functions are described on the following pages. The descriptions use the following format.

First, the function declaration is shown, including data types of parameters, followed by a short explanation of what the function does.

After that, in- and out parameters are described, together with possible return values and error codes.

SPInit

int SPInit(int toolType,
             *SPMList list);
SPInit initiates a session and establishes a connection with the PostMaster. See "Multiple PostMaster Instances" on page 2498 for information on how to connect to a specific instance of the PostMaster.

Inparameters

Returns

Errors

SPNOPOSTMASTER
SPTIMEDOUT
SPALREADYCONNECTED
SPNOMEMORY

SPExit

int SPExit(void);
SPExit exits a session and disconnects the connection with the PostMaster. Subsequent calls to PostMaster functions will return the error code SPNOSESSION until a new SPInit is performed.

Returns

Errors

SPNOCHANNEL
SPNOSESSION

SPSendToTool

int SPSendToTool(int tool,
                int event,
                void * data,
                int size); 
SPSendToTool sends a message to the process of kind type.

Inparameters

Returns

Errors

SPNOCHANNEL
SPNOSESSION
SPNOMEMORY
SPBADMESSAGE
SPINVALIDMESSAGE
SPTOOLNOTFOUND
SPBADMESSAGE
SPNOSUCHPID

SPSendToPid

int SPSendToPid(int pid,
                int event,
                void * data,
                int size); 
SPSendToPid sends a message to the process which has process id toPid.

Inparameters

Returns

Errors

SPNOCHANNEL
SPNOSESSION
SPNOMEMORY
SPBADMESSAGE
SPINVALIDMESSAGE
SPTOOLNOTFOUND
SPNOSUCHPID

SPBroadcast

int SPBroadcast(int event,
                void * data, 
                int size);
SPBroadcast sends a message to all processes that subscribes on the message type.

Inparameters

Returns

Errors

SPNOCHANNEL
SPNOSESSION
SPNOMEMORY
SPBADMESSAGE
SPINVALIDMESSAGE

SPRead

int SPRead(int timeOut
           int pid,
           int *message,
           void ** data,
           int * len);
SPRead reads a message from the queue of unread messages that the PostMaster has sent. When the message is read, it is also consumed, i.e. removed from the queue. The function allocates the necessary amount of memory needed for the data component in the message. The application using this function is responsible for freeing the allocated memory when it is no longer needed.

Inparameters

Outparameters

Returns

Errors

SPNOCHANNEL
SPNOMESSAGE
SPNOSESSION
SPNOMEMORY

SPErrorString

char * SPErrorString(int code);
               
Converts an error code into a textual string textual description of a tool or a message to the corresponding integer value.

Inparameters

Returns

An descriptive error string corresponding to the error code.

SP

int SP(char * str);
Converts a textual description of a tool or a message to the corresponding integer value as provided by the variable list in SPInit.

Inparameters

Returns

An integer value for the tool or message. If no mapping is found, SPERROR is returned.

Run-time Considerations

Starting Up the Tools

There are several possible ways to start the PostMaster itself and the tools that wish to communicate via the PostMaster. In principle, there are two main alternatives:

We will exemplify the start-up methods by using the DemonGame simulator and the demon UI described in "Example of Use" on page 502 in chapter 10, How to Use the SDT Public Interface.

--------------------------------------------------------------------
Note:                                                                 
The PostMaster must be started first, but the communicating tools     
may be started in any order. An SDT simulator must also execute the   
commands StartSDTEnv and Go before communication with an              
other tool can start.                                                 
--------------------------------------------------------------------

Starting when SDT is present

When SDT is started from the UNIX prompt, an instance of the PostMaster is automatically started. No additional commands are needed for the PostMaster in this case.

The DemonGame simulator is preferably started from SDT, thus giving access to all simulation features. It can also be started directly from the UNIX prompt with the command
DemonGame.sct -post. (Without the parameter, the simulator runs stand-alone, which is not desired in this case.) Starting the simulator this way restricts the possibilities of the simulation since there is no connection to the SDT tools. For instance, graphical trace is disabled.

The UI is preferably started directly from the UNIX prompt. It can also be started from the DemonGame simulator with the command StartUI, but this requires that the executable is named sdtenv. This is the name specified in the configuration for tool number 27000.

Starting without SDT

When SDT is not running, the PostMaster must be started directly from the UNIX prompt with the command $sdtbin/sdtpm & (possibly with an argument, see below).

The DemonGame simulator must also be started directly from the UNIX prompt, as described above.

----------------------------------------------------------------
Note:                                                             
If activating the PostMaster this way, the environment variable   
POSTPATH must be set to include the directory where the SDT exe   
cutables resides, typically $sdtbin.                              
----------------------------------------------------------------
The UI can be started in the same way as when SDT is running (see above). It can also be started indirectly when starting the PostMaster by using the UNIX command $sdtbin/sdtpm -clients 27000 &. This requires that the executable is named sdtenv, the name specified in the configuration for tool number 27000.

-------------------------------------------------------------------
Note:                                                                
A tool communicating through the PostMaster can also be started      
from another tool by using the SESTART message. This requires that   
the tool to be started is specified in the configuration.            
-------------------------------------------------------------------

SDT-2 connections

Applications or tools linked with an SDT 2.X PostMaster application library will not be compatible with SDT 3.X PostMaster. Trying to connect such an old application to an SDT 3.X PostMaster will result in an error message:

Postmaster cannot connect SDT2 tool:<tool> with pid: 
<pid>
on standard output, if externally started, or as a service reply, if started via the start service, and the connection is aborted.

Multiple PostMaster Instances

It is of course possible to have multiple instances of the PostMaster running, for instance when more than one SDT has been started. In this case it should be made sure that the communicating tools are connected to the correct instance of the PostMaster.

By default, the function SPInit looks for the PostMaster instance with the highest process id (PId) number and connects to it. To connect to another PostMaster instance, you can set the environment variable
sdtpostpid to the PId number of the desired PostMaster. If this variable is set, SPInit connects to the PostMaster instance with that PId number.

Configuration and Tool Search

The PostMaster configuration is read whenever a PostMaster instance is invoked. The environment variable POSTPATH defines a list of directories, each separated by a colon `:', where the PostMaster looks for a configuration file named post.cfd.

The user can extend the normal SDT configuration by defining the POSTPATH variable to a directory containing an extended configuration. When SDT is started normally, via its' start script, the directory containing the SDT binaries are put as the first directory in the POSTPATH variable.

The same search order is applied when the start service is used. The supplied tool number is matched against the name of an executable in the configuration, which is then searched for as above.

This page intentionally left blank

 
Table of Contents Next Chapter