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

Interprocessor Communication
HP NonStop S-Series Server Description Manual—520331-003
9-18
Reply and Reply Acknowledge
Reply and Reply Acknowledge
Every time a listener receives a request, whether short, medium, or long, it must
respond with a reply. That reponse occurs in a reply phase, which may or may not
necessarily include data. But whether or not reply data is included with the reply, the
linker, after it receives the reply, must respond with an acknowledgment.
Such a reply acknowledgment can be piggy-backed on some other message going to
the listener processor but, if not, a separate acknowledge reply tranmission is
required—thus both events are shown as separate phases in Figure 9-9.
Whenever a reply contains reply data, such as a reply to a read request , the reply
phase transfers data from a listener’s buffer to a linker’s buffer. Because the address of
the linker’s buffer is known to both the linker and the listener, it is not necessary to use
pre-push buffers for delivery of the reply data; data is transferred directly from one
client buffer to the other without intermediate copying.
The sequence of events, as illustrated in Figure 9-9, is as follows.
In the reply phase (where the request requires reply data), the listener process has
already read the request control information and now knows that it needs to reply with
the appropriate reply data. It creates its own control information in its reply control
buffer and calls the message system with MSG_REPLY_. The message system
accordingly creates a new TIB, which ServerNet services translates to BTE descriptors
(1).
When the BTE hardware transmits the reply message (2), it pre-pushes the reply
control packets, then all the data packets, and finally the setup packet. (This setup
packet, or possibly some prior setup packet, includes the request acknowledge
information.) These packets are received in order by the linker’s AVT hardware (3) and
stored according to their different contents. The reply control packets (4) and the reply
data packets (5) are stored in their respective linker buffers. The reply setup packet,
the last one to arrive, is sent to the interrupt queue (6), so that the message system,
when interrupted, can alert the linker process that the reply data has been received.
In the acknowledge reply phase, the linker process calls its message system with a
MSG_BREAK_ call to send a final reply back to the listener (acknowledging receipt of
the reply message) and to retire the original request message. If possible (often the
case), the message system will include (piggy-back) the acknowledge-reply
information in some other message going to the same destination. Otherwise, the
message system builds a simple TIB (7), which gets translated to a BTE descriptor (8),
and a resulting interrupt packet is sent through the ServerNet hardware (9) to the
listener’s interrupt queue (10). The message system on the listener side, when
interrupted, then alerts the listener process that the reply message has been received
by the linker, and resources used by this read request can be freed.