Open System Services Programmer's Guide

delivery of each message. The following list shows the order of increasing overhead (decreasing
performance) for AF_UNIX Release 2 processes and sockets:
1. Both processes are in the same processor and their sockets were created in that processor.
2. The processes are in different processors and each process is using a socket created in
its processor.
3. One of the processes resides in a processor other than where its socket was created.
4. Both processes reside in processors other than where their socket was created.
• OSS AF_UNIX Release 1 sockets and OSS AF_INET and AF_INET6 sockets involve multiple
system processes in the data path for each message, even if both ends of the connection are
on the same processor; as a result, the socket overhead is much higher than for other
interprocess communication mechanisms. The following tradeoffs exist for the use of OSS
AF_UNIX Release 1 sockets, AF_INET sockets, and AF_INET6 sockets:
◦ If you must have portability and POSIX standard sockets semantics, use OSS sockets.
◦ If you require improved performance with sockets-like semantics but portability is not a
primary consideration, consider using Guardian sockets. The use of Guardian sockets
for NonStop TCP/IP, Parallel Library TCP/IP, and NonStop TCP/IPV6 is described in the
TCP/IP Programming Manual.
◦ If you require even higher performance and can abandon portability and sockets
semantics, consider using $RECEIVE. Refer to the Guardian Programmer’s Guide for more
information about programs that use $RECEIVE.
◦ If you require maximum performance with portability and can abandon sockets semantics,
use OSS pipes or FIFO files. OSS pipes and FIFOs typically provide a direct data path
without intervening system processes.
OSS Interprocess-Communication Functions
Table 20 (page 197) displays information about each OSS function that you can use for interprocess
communication. The columns of the table contain the following:
OSS Function
The name of the function and a brief description.
OSS Notes
Notes about the OSS implementation of the function. The note “Can return extended errors”
means that the function can return errors that are HP extensions to the XPG4 specification.
Refer to the function’s reference page for further information.
Beginning with the J06.15 and H06.26 RVUs, a partner or customer OSS Security Event-Exit
Process (SEEP) is supported and can participate in access-control decisions for OSS objects.
(For OSS SEEP details, see “Accessing OSS SEEP-Protected Files” (page 83).) The note “OSS
SEEP consultation” indicates that the OSS name server consults the OSS SEEP when this function
is called for operations on files in OSS SEEP-protected filesets and the OSS SEEP is running.
Guardian Notes
Notes about using the function when it is called from a Guardian process.The note “FDM set”
(for file, directory, and memory) means that the function is one of a set of functions that have
the following effects when the first of them is called from the Guardian environment:
• Two Guardian file-system numbers (not necessarily the next two available) are allocated
for the root directory and the current working directory. These file numbers cannot be
closed by calling the Guardian FILE_CLOSE_ procedure.
• The current working directory is assigned from the VOLUME attribute of the Guardian
environment =_DEFAULTS DEFINE.
196 Interprocess Communication