An I/O port ``opened'' for operations on a process, rather than on a file or device, forms part of a point-to-point IPC link. Such a link can be fully specified as a pair of pairs
((process A, port X), (process B, port Y))In other words, an IPC link is established by ``connecting'' two I/O ports. Consequently, an operating system need only add a system call for connecting I/O ports, in order to include IPC into the realm of classical I/O:
Connect (ProcessA, PortX, ProcessB, PortY)
A security conscious operating system can make this call safe by placing restrictions on allowable values for ProcessA and ProcessB. For example, if ProcessA or ProcessB is not the process number of the process executing Connect, then the operating system may require that it should be the process number of a child process. In other words, a process will be restricted to communicate only with its siblings and children.
This is not as severe a restriction as it may sound, since an arbitrarily interconnected network of processes can readily be set up, simply by loading them all from a common parent. And it does have the significant advantage that processes need never deal with stray or malicious messages.
Of course, such a restriction will make it impossible for a user process to use Connect to set up IPC links to multi-user servers that should already be part of the environment when the process starts up.
Fortunately, such server processes can readily be viewed as abstract devices. Consequently, I/O ports used for IPC between ``user'' process and ``server'' process would be opened for operations by using the classical system call:
Open (process-num, io-port, object, desired-ops)where process-num denotes the process whose port is to be opened (either the calling process or one of its child processes), and object denotes the file, device, or server that is the target of the operations. Desired-ops denotes the set of operations the caller intends to be carried out. For example, desired-ops = {Read}, indicates that the object is to be opened in read-only mode.
This convention enables server processes to be integrated into the name space used to identify files and devices, and allows the operating system to regulate the creation, visibility and accessibility of servers in exactly the same way as for files. The conceptual simplication brought about by this strategy should not be underestimated.
Prof Herman Venter