IPC across the network

A QNX application can talk to a process on another computer on the network just as if it were talking to another process on the same machine. From the application's perpective, there is no difference between a local and remote resource. This transparency is made possible by virtual sircuits (VCs), which are paths the Network Manager provides to transmit messages, proxis, and signals across the network. VCs contribute to efficient overall use of resources in a QNX network for several reasons:

When a VC is created, it has given the ability to handle messages up to a specified size; this means you can preallocate resources to handle the message. When you need to send a message larger than the maximum specified size, the VC is automatically resized to accomodate the larger message.
If two process residing on different nodes are communicating with each other via more than one VC, the VCs are shared, only one real virtual circuit exists between the processes. This situation occurs commonly when a process acesses several files on the remote filesystem.
If a process attaches to an existing shared VC and it requests a bufefr size larger than that currnetly in use, the buffer size is automatically increased.
When a process terminates, its associated VCs are automatically released.

A sending process is responsible for setting up the VC between itself and the process it wants to communicate with. To do so the sending process usually issues a qnx_vc_attach() function call. in addition to creating a VC, this call also creates a virtual process ID, or VID, at each end of the circuit. To the process at either end of the virtual circuit, the VID on its end appears to have the process ID of the remote process it wants to communicate with. Processes communicate with each other via these VIDs.

In the previous example the virtual circuit connects PID 1 to PID 2. On node 4 where PID 1 resides a VID represents PID 2. On node 5 where PID 2 resides, a VID represents PID 1. Both PID 1 and PID 2 can refer to the VID on their node as if it were any other local process, sending messages, receiving messages, raising signals, waiting, etc. For example, PID 1 can send a message to the VID on its end, and this VID will relay the message across the network to the VID representing PID 1 on the other end. This VID will then route the message to PID 2. Each VID maintains a connection that contains the following information:

local pid
remote pid
remote nid (node ID)
remote vid

You do not need to contact VC directly. When az application wants to access an I/O resource across the network, a VC is created by the open() function. To the application, the VC simply appears to be a PID.

A process might become unable to communicate over an established VC for various reason:

The computer it was running on was powered down.
The network cable to the computer was disconnected.
The remote process it was communicating with was terminated.

The process manager on each node checks the integrity of VCs on its node. It does this as follows:

Each time a successful transmission takes place on a VC, a time stamp associated with the VC is updated to indicate the time of last activity.
At installation-defined intervals, the Process Manager looks at each VC. If there's been no activity on a circuit, the Process Manager sends a network integrity packet to the Process Manager on the node at the other end of the circuit.
If no response comes back, or if a problem is indicated, the VC os flagged as having a problem. An installation-defined number of attempts are then made to re-establish contact.
If the attempts fail, the VC is dismantled; any processes blocked on the VC is made READY. (The process sees a failure return code from the communication primitive on the VC.)