Open System Services Porting Guide (G06.29+, H06.06+, J06.03+)

1
Applies to both AF_UNIX Release 2 sockets and earlier AF_UNIX sockets. However, AF_UNIX Release 2 sockets must
be of the same mode (compatibility mode or portability mode) to communicate with each other. For more information,
see the Open System Services Programmer's Guide
Table 7 lists the interprocess-communication methods available to an OSS process using both OSS
and Guardian APIs, and the capabilities of each API relevant to communication between processors
and nodes. The methods are listed in an order consistent with Table 6.
Table 7 Interprocess Communication Using OSS and Guardian APIs
With other systemsBetween Expand
nodes
Between processorsWithin a processorIPC method
YesYesYesYesGuardian AF_INET
and AF_INET6
sockets
YesYesYesYesOSS AF_INET and
AF_INET6 sockets
NoNoYesYesOSS AF_UNIX
sockets
1
NoNoYesYesPipes (with OSS
processes only)
NoYesYesYesFIFOs
NoNoYesYesMessage queues (with
OSS processes only)
NoNoYesYesOSS signals
NoNoNoYesGuardian binary
semaphores
NoNoNoYesShared memory
2
NoNoNoYesOSS semaphores (with
OSS processes only)
NoYesYesYes$RECEIVE
1
Applies to both AF_UNIX Release 2 sockets and earlier AF_UNIX sockets. However, AF_UNIX Release 2 sockets must
be of the same mode (compatibility mode or portability mode) to communicate with each other. For more information,
see the Open System Services Programmer's Guide
2
On servers running J06.12 or later J-series RVUs or H06.23 or later H-series RVUs, Guardian processes can use OSS
function calls to access shared memory. See “Using Shared Memory” (page 93) for more information.
For a discussion of interprocess communication between Guardian and OSS processes, refer to
the Open System Services Programmer’s Guide. It includes interoperability tables, listing Guardian
procedures and OSS functions that support interoperability between the Guardian and OSS
environments.
Traditional UNIX applications on shared memory systems are often written using the assumption
that process creation and interprocess communication (IPC) are relatively cheap operations. These
applications commonly have a server process that uses fork() to create a child process for each
work request; the parent and child processes communicate using an IPC mechanism. Given the
shared-nothing architecture of the NonStop system, operations such as process creation and IPC
might use significantly more processor resources when a UNIX application is ported without change.
Refer to “Porting Servers and Demons” (page 103) for a discussion of this situation.
Using Sockets
A socket is an end-point for communication between two processes. A socket is similar to a file in
that a process can create a socket, write data to it, read data from it, and close it without regard
Using Interprocess Communication (IPC) Mechanisms 89