An IPC Channel Interface

There are some advantages in designing a narrow communication interface: first, the lifetime of software projects, especially in research areas like high energy or plasma physics grows continuously. Such projects are often designed for time spans of a decade. Within such scales upgrades will be done several times and a standardised, yet simple interface is the only way to provide ease of maintenance. Second, the systems are built several years before going into operation. Technologies are chosen for prototyping that may be different from those, which are used in the production system. The interface allows transparent replacement of the lower level. Third, if implemented as a component[PS96] it enables us to use any byte transfer mechanisms: streams or discrete messages, connection oriented as well as connection less. Details, like how to open a channel can be hidden from the application layer. The interface outlined in figure 38 is narrow yet sufficiently flexible. When opening a channel between two nodes, two addresses have to be passed. We suggest to having a base class from which concrete addressing schemes as used in the Internet or FibreChannel domain can be used. All data transfer, whether connection-oriented or connection-less, datagram or stream-oriented can be unified to a byte stream oriented mode of operation. For receiving messages, at most two calls are needed. One that returns as soon as data are available ( recv), and one that returns the control back to the application only if the required amount of data are consumed ( recv_n). For sending, equivalent functions shall be provided. Even in presence of fixed sized datagrams we can show (see section 5.7.1) that such byte stream semantics can be met. General set and get operations allow to access management data structures. They should not grant access to embedded functionality directly, such as flags that can be set when using the socket interface. Instead a common data structure for specifying qualities of service (mode of operation, protocol settings, network specific attributes) should be provided. Following this principle, even exchanging of the chosen data transport architecture might allow qualities of service parameters to be used at a higher level.