NonStop S-Series Server Description Manual (G06.24+)

Interprocessor Communication
HP NonStop S-Series Server Description Manual—520331-003
9-4
Linker-Listener Protocol
Linker-Listener Protocol
Figure 9-2 separately shows the linker-listener protocol as if lower levels of protocol did
not exist. However, it is those lower levels that actually carry out the actions shown
here.
The linker-listener protocol consists of a request (1) and a reply (2). Optionally, data
can be included in either the request or the reply—or both or neither, depending on
what the linker process wants to do. Data included in the request is called request
data, and data included in the reply is called reply data.
Control information is always included in a message. This control information is stored
in buffers that are physically separate from the data buffers and are called request
control buffers and reply control buffers. For simplicity, however, Figure 9-2 combines
control and data storage, and considers all these buffers to be “data” buffers.
The linker process begins the communication by invoking the message system,
instructing it to send request control information (and optionally data, such as for a
write request) to the listener process. The message-system call used by the linker to
create and send the message is MSG_LINK_.
After the listener processor has received the message, the listener processor
immediately stores the control information (and request data, if any) either directly in
the listener’s request data buffer (as shown) or in temporary space in a cache or small
buffer—depending on the combined size of the control and data. Then the message
system alerts the listener process that a message has arrived. Accordingly, the listener
process calls its message system with MSG_LISTEN_ to find out basic information
about the message: its size, message identification, whether request data was
included,and so on. With that information, the listener again calls the message system
with MSG_READCONTROL_ to obtain the control information, which provides
processing requirements, such as reading or writing data. If request data was stored in
a cache, the listener also calls MSG_READDATA_ to transfer the message data into its
request data buffer.
After the request has been fully handled, the listener again calls its message system
(with MSG_REPLY_) to send a reply message back to the linker process. The reply
message always contains control information, providing status about the status of the
request. This informs the linker that the data has (or conceivably has not) been written.
If reply data is to be included in the reply, such as for a read request, the listener
includes such data in its reply.
When the linker processor receives the reply message, it immediately stores the reply
data in the linker’s reply data buffer, and the message system alerts the linker process
that a message has arrived. Accordingly, the linker uses MSG_BREAK_ to obtain the
reply control information from the message system, which provides status information
about the listener’s handling of the original request. This call also informs the linker
that reply data, if any, is present in the reply data buffer.