The difficulty of developing reliable distributed softwme is an impediment to applying distributed computing technology in many settings. Expeti _ with the Isis system suggests that a structured approach based on virtually synchronous _ groups yields systems that are substantially easier to develop, exploit sophisticated forms of cooperative computation, and achieve high reliability. This paper reviews six years of resemr,.hon Isis, describing the model, its impl_nentation challenges, and the types of applicatiom to which Isis has been appfied. 1 In oducfion One might expect the reliability of a distributed system to follow directly from the reliability of its con-stituents, but this is not always the case. The mechanisms used to structure a distributed system and to implement cooperation between components play a vital role in determining how reliable the system will be. Many contemporary distributed operating systems have placed emphasis on communication performance, overlooking the need for tools to integrate components into a reliable whole. The communication primitives supported give generally reliable behavior, but exhibit problematic semantics when transient failures or system configuration changes occur. The resulting building blocks are, therefore, unsuitable for facilitating the construction of systems where reliability is impo/tant. This paper reviews six years of research on Isis, a syg_,,m that provides tools _ support the construction of reliable distributed software. The thesis underlying l._lS is that development of reliable distributed software can be simplified using process groups and group programming too/_. This paper motivates the approach taken, surveys the system, and discusses our experience with real applications.

ly, the remote procedure call problem, which an RPC protocol undertakes to solve, consists of emulating LPC using message passing. LPC has a number of "properties" -- a single procedure invocation results in exactly one execution of the procedure body, the result returned is reliably delivered to the invoker, and exceptions are raised if (and only if) an error occurs. Given a completely reliable communication environment, which never loses, duplicates, or reorders messages, and given client and server processes that never fail, RPC would be trivial to solve. The sender would merely package the invocation into one or more messages, and transmit these to the server. The server would unpack the data into local variables, perform the desired operation, and send back the result (or an indication of any exception that occurred) in a reply message. The challenge, then, is created by failures. Were it not for the possibility of process and machine crashes, an RPC protocol capable of overcomi...

Many mobile computing applications can profit from process groups and reliable multicast communication to maintain replicated data, but most operating systems available todayfailinproviding the primitive operations needed bysuch applications. In this paper we describe a highly configurable, Generic Multicast Transport Service (GTS), which supports the implementation of group-based applications in wide-area settings. GTS is unique in that it offers fault-tolerant, order-preserving multicast on arbitrary communication protocols, including e-mail. As another distinguishing mark, messages can be sent to processes even when they are temporarily unavailable, which permits disconnected operation and mobility.We further propose an object-oriented system design consisting of adaptor objects interconnected to form a protocol tree. Adaptor objects offer a common interface to dissimilar communication protocols, and make it easy to incorporate new protocols into GTS. Currently, GTS is being used in a cooperativesoftware engineering environment and in other projects. GTS is available for anonymous ftp.

w _ ! hou_m_mmoMe,mck_n0met_n* _ m_mtngtmlmctiom. **mchl_evktm0(kenNm_. imbed0_ nolinlommton. Sen4cbmmmsmgwmng m_ _ _lm w anyomitmp _ nlmbooaec_d k_om_

This paper discusses the issues involved in the design of a good distributed system. It objectively compares (as far as possible) the handling of these design issues in Amoeba, Consul and Transis - some of the tools developed for this purpose, contrasting them with Isis/Horus - the toolkit that we have studied in depth. Contents 1 Introduction 3 2 Toolkits versus operating systems 3 3 The meat of the matter.. 4 3.1 Support for process groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.2 Virtual synchrony and membership services . . . . . . . . . . . . . . . . . . . . . . . 5 3.3 Multicast protocols and their efficiency . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.4 Support for non-primary partitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.5 Communication protocols and flow control . . . . . . . . . . . . . . . . . . . . . . . . 7 3.6 Long haul support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3...