Recently, OS engineers have started to address the problem of writing portable code that deals directly with the network interface. To this end, the Data Link Provider Interface (DLPI) was introduced in the System V release of Unix. Using DLPI consists of specifying an option either to the socket() call or through an API of its own. DLPI does not require that the operating system provide for asynchronous or signal-driven operation; however, nonblocking routines are part of its specification. Unfortunately, DLPI was not adopted by those companies marketing a OS that was not a System V derivative. Instead, these companies chose to develop their own interface. Nevertheless, the ideas of offering the user simple and complete access to the media as well as ability to easily switch from one packet format to another seem to have survived. If PVM does adopt a system daemon, DLPI and its non-System V analogues may be the best solution.
An even further abstraction from the hardware is the IP layer. IP offers a number of advantages. For instance, it performs a header checksum that is essentially free. Its sockets can be set up to provide both asynchronous and nonblocking operation. And most important, any layer written using IP would very portable. On the other hand, many of IP's extra features come with a hefty price tag. For example, fragmentation and reassembly mean that buffering is performed in the kernel. This in turn means that we must incur the cost of allocating and copying blocks of memory during each operation. Another feature, flow control, can affect performance by having too sophisticated an algorithm, as well as by flooding the network with explicit control messages. Furthermore, these two features can cause a process to block, thus further affecting performance through unnecessary context switching and kernel overhead.