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.
Refer to the following sections to learn more about SRC communication types:
The Communications Between the srcmstr Daemon and Subsystems table summarizes communication type actions associated with SRC functions.
Function | Using IPC or sockets | Using signals |
---|---|---|
start | ||
subsystem | SRC forks and execs to create subsystem process. | SRC forks and execs to create subsystem process. |
subserver | Uses IPC message queue or socket to send request to subsystem. | Not supported |
stop normal | ||
subsystem | Uses IPC message queue or socket to send request to subsystem. | Sends SIGNORM to the subsystem. |
subserver | Uses IPC message queue or socket to send request to subsystem. | Not supported. |
stop forced | ||
subsystem | Uses IPC message queue or socket to send request to subsystem. | Sends SIGFORCE to the subsystem. |
subserver | Uses IPC message queue or socket to send request to subsystem. | Not supported. |
stop cancel | ||
subsystem | Sends SIGTERM followed by SIGKILL to the process group of the subsystem. | Sends SIGTERM followed by SIGKILL to the process group of the subsystem. |
status short | ||
subsystem | Implemented by SRC (no subsystem request). | Implemented by SRC (no subsystem request). |
subserver | Uses IPC message queue or socket to send request to subsystem. | Not supported. |
status long | ||
subsystem | Uses IPC message queue or socket to send request to subsystem. | Not supported. |
subserver | Uses IPC message queue or socket to send request to subsystem. | Not supported. |
traceon/traceoff | ||
subsystem | Uses IPC message queue or socket to send request to subsystem. | Not supported. |
subserver | Uses IPC message queue or socket to send request to subsystem. | Not supported. |
refresh | ||
subsystem | Uses IPC message queue or socket to send request to subsystem. | Not supported. |
subserver | Uses IPC message queue or socket to send request to subsystem. | Not supported. |
notify | ||
subsystem | Implemented by subsystem-provided method. | Implemented by subsystem-provided method. |
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.
Item | Descriptor |
---|---|
addssys | Adds a subsystem definition to the SRC configuration database |
defssys | Initializes a new subsystem definition with default values |
mkssys | Adds a subsystem definition to the SRC configuration database |
Sockets communication
Increasingly, the communication option of choice for subsystem programmers is sockets. Sockets are also the default communication type for the srcmstr daemon. See the Sockets OverviewCommunications 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:
- 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.
- 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.
- 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.
- 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.
- 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.
Item | Descriptor |
---|---|
srcrrqs | Saves the destination address of your subsystem's response to a received packet. (Also see threadsafe version srcrrqs_r) |
srcsrpy | Sends your subsystem response packet to a request that your subsystem received. |
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:
- The srcmstr daemon gets the message queue ID from the SRC subsystem object and sends the message to the subsystem.
- 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.
- The subsystem calls the srcrrqs subroutine to get a tag ID that is used in responding to the message.
- 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.
- The subsystem calls the srcsrpy subroutine to send back a reply buffer to the command process.