This paper describes a new operating system kernel, called the x-kernel, that provides an explicit architecture for constructing and composing network protocols. Our experience implementing and evaluating several protocols in the x-kernel shows that this architecture is both general enough to accommodate a wide range of protocols, yet efficient enough to perform competitively with less structured operating systems. 1 Introduction Network software is at the heart of any distributed system. It manages the communication hardware that connects the processors in the system and it defines abstractions through which processes running on those processors exchange messages. Network software is extremely complex: it must hide the details of the underlying hardware, recover from transmission failures, ensure that messages are delivered to the application processes in the appropriate order, and manage the encoding and decoding of data. To help manage this complexity, network software is divi...

Sprite is a new operating system for networked uniprocessor and multiprocessor workstations with large physical memories. It implements a set of kernel calls much like those of 4.3 BSD UNIX, with extensions to allow processes on the same workstation to share memory and to allow processes to migrate between workstations. The implementation of the Sprite kernel contains several interesting features, including a remote procedure call facility for communication between kernels, the use of prefix tables to implement a single file name space and to provide flexibility in administering the network file system, and large variable-size file caches on both client and server machines, which provide high performance even for diskless workstations.

Code to implement network protocols can be either inside the kernel of an operating system or in user-level processes. Kernel-resident code is hard to develop, debug, and maintain, but user-level implementations typically incur significant overhead and perform poorly. The performance of user-level network code depends on the mechanism used to demultiplex received packets. Demultiplexing in a user-level process increases the rate of context switches and system calls, resulting in poor performance. Demultiplexing in the kernel eliminates unnecessary overhead. This paper describes the packet filter, a kernel-resident, protocolindependent packet demultiplexer. Individual user processes have great flexibility in selecting which packets they will receive. Protocol implementations using the packet filter perform quite well, and have been in production use for several years.

Network software is a critical component of any distributed system. Because of its complexity, network software is commonly layered into a hierarchy of protocols, or more generally, into a protocol graph Typical protocol graphs-including those standardized in the IS0 and TCP/IP network architectures-share three important properties: the protocol graph is simple, the nodes of the graph (protocols) encapsulate complex functionality, and the topology of the graph is relatively static. This paper describes a new way to organize network software that differs from conventional architectures in all three of these properties In our approach, the protocol graph is complex, individual protocols encapsulate a single function. and the topology of the graph is dynamic. The main contribution of this paper is to describe the ideas behind our new architec-ture, illustrate the advantages of using the architecture, and demonstrate that the architecture results in efficient network software.

Abstract not found

Abstract not found

This paper argues that a shared, distributed name space and I/O interface should be implemented inside the operating system kernel. The grounding for the argument is a comparison between the Sprite network operating system and the Mach microkernel. Sprite optimizes the common case of file and device access, both local and remote, by providing a kernel-level implementation. Sprite also allows for user-level extensibility by letting a user-level process implement the naming and I/O interfaces of the file system. Mach, in contrast, provide general interprocess communication and does not define a file system protocol in the kernel. [Published in the Proceedings of the 2nd USENIX Mach Symposium, Nov 20-22, 1991, pages 233250 ] 1 Introduction This paper argues that the file system is a mature enough abstraction that it should be implemented inside the operating system kernel for optimal performance. Data storage and high-level naming are fundamental features of today's computer syste...

Introduction The work presented in this dissertation was motivated by two recent changes in technology: networks and large memories. The introduction of networks has led to a move away from centralized timesharing operating systems towards network operating systems. In these network operating systems each user has a personal highperformance workstation and communicates with other users across a network. Data that was once stored on a single set of disks in the timesharing systems is now distributed amongst the disks of several workstations. In fact, many of the workstations do not have any disk at all; the data for these diskless workstations is stored across the network on the disks of other workstations. The move towards network operating systems poses two problems: how to provide users with high performance and how to allow users to easily share data. Performance is a problem in network environments because each access of data may require both a network access and a disk acc

In spite of the fact that the works about distributed operating systems has been very active, it seems that the importance of network layer protocols in distributed environments is scarcely recognized. This paper describes the basic design of the Muse-IP, a network layer protocol, which is suitable for large distributed systems with mobile hosts such as lap-top computers. The Muse-IP is based on ISO CLNP for the sake of compatibility and adds some features to it. The Muse-IP exploits the interface information to eliminate redundant processing. The addressing scheme of the Muse-IP can make routing functions easier and support mobile hosts in the internet. The Muse-IP can also provide realtime communications by predicting the communication time between source and destination hosts. The Muse-IP is being implemented in the Muse operating system as a network layer protocol. 1 INTRODUCTION Several distributed operating systems such as V-system, DASH, Sprite, and Mach, have been designed an...

This paper gives a survey of all common transparent distributed systems. We distinguish between Distributed File Systems (DFS) and Distributed Operating Systems (DOS). Our overview is focussed on systems providing at least access or location transparency. The paper is organized as follows: The introduction offers definitions of the features of each transparent distributed system as well as the services it is able to provide. We also propose a catalog of criteria that enables us to compare different systems independently of implementation done. The main entries we make are heterogeneity of the system's environment, communication strategy, as well as naming and security issues. Finally, we examine the reliability and availability of the separate systems and the way these issues are achieved. The following section consists of the survey. The description of each system is organized as follows: First, we introduce the main goal the system was developed for, the classification of th...