Since the generalized I/O call should be the only explicit support given to IPC by the operating system, the implementation of IO should be as efficient as is possible. This rules out the use of a ``heavy weight'' protocol that ensures correct operation despite network failures.
When used for IPC, Initiate-IO should do little more than:
Furthermore, Complete-IO should do little more than:
However, protocol/hardware specific details, such as having to ``packetize'' messages, should naturally not be the concern of the programmer using IO. Which is to say that IO should support the exchange of arbitrarily sized messages over fallible virtual circuits.
Reliable IPC can readily be constructed on top of IO, provided that the semantics presented thus far are extended as follows:
Retry-IO should be the same as Initiate-IO, except that the resulting message should be sent with the same sequence number used for the message which received no reply. This will enable the message to be discarded as a duplicate if the original message actually was delivered.
Apart from returning with an error code when a time-out occurs, Complete-IO should also return an error code when the operating system discovers that the request message is non-deliverable. A distributed OS can ensure that remote crashes are detected by requiring the remote kernel to send a ``reassuring'' reply to the local kernel, in answer to any message sent by Retry-IO. Failure to receive reassurance after a fixed number of retries could then be interpreted as a remote crash. Furthermore, a negative reply by the remote kernel can be used to indicate that the recipient process no longer exists.
Despite the fact that IO does not make network errors transparent to the programmer, it should not be assumed that IO should therefore not be used ``as is'' for IPC. Most uses of IPC occur in systems where the communications hardware (if any) are inherently reliable anyway. Network errors are therefore likely to be rare (much like classical I/O errors) and it will often be quite acceptable to simply abort a process encountering an error.
If aborting on occurence of a network error is not acceptable, then aborting on the occurence of a remote node/process failure is not likely to be acceptable. Since these errors are all detected in the same way (Complete-IO returns an error code), a fault-tolerant distributed software system may as well use a single error-recovery mechanism to recover from both communication failures and remote failures.
Prof Herman Venter