SRC Communication Types

The System Resource Controller (SRC) supports three communication types: signals, sockets, and interprocess communication (IPC) message queues. The communication type chosen determines to what degree the subsystem takes advantage of SRC functions.

Note: All subsystems, regardless of the communication type specified in the subsystem environment object, must be capable of supporting limited signals communication. A signal-catcher routine must be defined to handle SIGTERM (stop cancel) signals. The SIGTERM signal indicates a subsystem should clean up all resources and terminate.

To learn more about SRC communication types, see:

• Signals Communication
• Sockets Communication
• IPC Message Queue Communication

The Communications Between the srcmstr Daemon and Subsystems table summarizes communication type actions associated with SRC functions.

Signals Communication

The most basic type of communication between a subsystem and the srcmstr daemon is accomplished with signals. Because signals constitute a one-way communication scheme, the only SRC command that signals subsystems recognize is a stop request. Subsystems using signals do not recognize long status, refresh, or trace requests. Nor do they recognize subservers.

Signals subsystems must implement a signal-catcher routine, such as the sigaction, sigvec, or signal subroutine, to handle SIGNORM and SIGFORCE requests.

Signals subsystems are specified in the SRC subsystem object class by issuing a mkssys -Snf command string or by using the defssys and addssys subroutines.

Sockets Communication

Increasingly, the communication option of choice for subsystem programmers is sockets. This is also the default communication type for the srcmstr daemon. See the "Sockets Overview" in AIX Communications Programming Concepts for more information.

The srcmstr daemon uses sockets to receive work requests from a command process. When this communication type is chosen, the srcmstr daemon creates the subsystem socket in which the subsystem will receive srcmstr daemon requests. UNIX sockets (AF_UNIX) are created for local subsystems. Internet sockets (AF_INET) are created for remote subsystems. The following steps describe the command processing sequence:

1. The command process accepts a command from the input device, constructs a work-request message, and sends the work-request UDP datagram to the srcmstr daemon on the well-known SRC port. The AF_INET is identified in the /etc/services file.
2. The srcmstr daemon listens on the well-known SRC port for work requests. Upon receiving a work request, it tells the system to fill the socket subroutine's sockaddr structure to obtain the originating system's address and appends the address and port number to the work request.
3. The srcmstr daemon uses the srcrrqs and srcsrpy subroutines. It processes only those requests that it can process and then sends the information back to the command process. Other requests are forwarded to the appropriate subsystem on the port that the subsystem has specified for its work requests.
4. The subsystem listens on the port previously obtained by the srcmstr daemon for the subsystem. (Each subsystem inherits a port when the srcmstr daemon starts a subsystem.) The subsystem processes the work request and sends a reply back to the command process.
5. The command process listens for the response on the specified port.

The file access permissions and addresses of the sockets used by the srcmstr daemon are maintained in the /dev/SRC and /dev/.SRC-unix temporary directories. Though displayable using the ls command, the information contained in these directories is for internal SRC use only.

Message queues and sockets offer equal subsystem functionality.

The Sockets Subsystem Communication Model for SRC figure depicts this process. See "Programming Subsystem Communication with the SRC" for more information.

IPC Message Queue Communication

IPC message queue functionality is similar to sockets functionality. Both communication types support a full-function SRC environment.

When the communication type is IPC message queue, the srcmstr daemon uses sockets to receive work requests from a command process, then uses an IPC message queue in which the subsystem receives SRC messages. The message queue is created when the subsystem is started, and is used thereafter. Message queue subsystems use the following command-processing sequence to communicate with the srcmstr daemon:

1. The srcmstr daemon gets the message queue ID from the SRC subsystem object and sends the message to the subsystem.
2. The subsystem waits for the message queue and issues a msgrcv subroutine to receive the command from the message queue in the form of the subreq structure required of subsystem requests.
3. The subsystem calls the srcrrqs subroutine to get a tag ID that is used in responding to the message.
4. The subsystem interprets and processes the received command. Depending upon the command, the subsystem creates either a svrreply or statcode data structure to return a reply to the command process. Refer to the /usr/include/spc.h file for more information on these structures.
5. The subsystem calls the srcsrpy subroutine to send back a reply buffer to the command process.

The IPC Message Queue Subsystem Communication Model for SRC figure depicts this process. See "Message Queue Kernel Services" in AIX Kernel Extensions and Device Support Programming Concepts for additional information on this communication type. See "Programming Subsystem Communication with the SRC" for the next step in establishing communication with the srcmstr daemon.

Related Information

System Resource Controller (SRC) Overview for Programmers.

Understanding SRC Objects.

Programming Subsystem Communication with the SRC

Defining Your Subsystem to the SRC.

The spc.h file.

The msgrcv subroutine, signal subroutine, socket subroutine, srcrrqs subroutine, srcsrpy subroutine.