An Operating Systems Vade Mecum

302 Co-operating Processes Chapter 9the identity of the return port so that Finger would know where to answer.Not all port designs share the properties we used in this Finger example. In the followingsections, we will distinguish different port philosophies.Data.Just like pipes, ports can be distinguished by whether they are delimitingand by whether they have broadcast. Some ports allow arbitrarily long messages,whereas others restrict message size, often to just a few bytes.Another distinction involves reliability. Messages sent between computers can failto arrive or can be garbled because of noise and contention for the communication line.As we saw in Chapter 5, there are techniques to increase the reliability of data transfer.However, these techniques cost both extra space (longer messages to increase redundancy,more code to check the messages) and time (delays and retransmissions). Sometypes of inter-process communication do not require a high degree of reliability. Forexample, the transfer may be part of a transaction (as described in Chapter 6) with itsown consistency checks and the ability to abort cleanly if it fails. In such a context, reliabilityat the lower levels of communication (making sure that each transmission succeedsor that each message arrives) cannot itself ensure success of the overall transaction. Theonly reason to pay for reliability at the lower levels is to increase the overall efficiency ofthe transaction by decreasing the likelihood that it will have to be repeated.A final data issue is whether messages sent to a port are received in the order inwhich they are sent. Differential buffering delays and routings, especially in a networkenvironment, can place messages out of order. It takes extra effort (in the form ofsequence numbers and, more generally, time stamps) to ensure order. For inter-processcommunication within one computer, however, order is usually easy to guarantee.Access.Pipes allow any number of writers and readers, although usually thereis only one of each. Different approaches to inter-process communication have beendesigned that impose various restrictions on the access to ports. A bound port is themost restrictive: There may be only one writer and one reader. This restriction allows theoperating system to implement the port with great efficiency. The state of the port can bedescribed by considering only two processes. Unread data may be buffered by the portmanager as part of the reader’s process state.At the other extreme, the free port allows any number of writers and readers. Wehave seen that free broadcast ports are complex. Even without broadcast, free ports aremore complex. For example, unread data cannot be stored as part of the state of any oneprocess but must be kept as part of the port itself. In cases of network operating systems,the port’s data storage may end up on a machine distant from both readers and writers,with the result that extra inter-machine messages are needed to complete a transfer.Between these extremes are input ports and output ports. An input port has onlyone reader but any number of writers. This arrangement is useful in the situation inwhich any number of clients may need help from the same server. Operating systemsthat provide input ports usually consider each port to belong to the process that can readfrom it. Such a concept of ownership does not apply to free or bound ports.Output ports, in contrast, are not particularly useful: They allow any number ofreaders but only one writer. One application for such a port is for print servers. Assumethat a process has many unrelated sets of data to print. It could send each as a message to