P. Alsberg and J. Day. A principle for resilient sharing of distributed resources. In Proceeding of ICSE, 1976.  Home/Search   Document Not in Database   Summary   Related Articles   Check

....to maintain consistency among replicas when serializing client operations. Several notions of consistency have been de ned. The strongest notion is atomicity, requiring that replicas emulate a single centralized object. Methods to achieve atomicity include write all read one [3] primary copy [1, 18, 17], majority consensus [19] and quorum consensus [11] Achieving atomicity often incurs a high cost, while some applications, such as directory services [20, 21] are willing to tolerate some transient inconsistencies. This gives rise to di erent notions of consistency. Sequential consistency [14] ....

P. Alsberg and J. Day. A principle for resilient sharing of distributed resources. In Proceedings of the 2nd International Conference on Software Engineering, pp. 627644, Oct. 1976.

....concepts described in this paper we make use of the two phase locking (2PL) protocol (i.e. all locks within a transaction precede all unlocks) as introduced in [14] This concurrency control technique is widely used in most database management systems. Many variations on the 2PL technique exist [1, 23, 17, 21]. Apart from two phase locking, other concurrency control mechanisms exist, like timestamp ordering (TO) techniques [22] and optimistic schedulers [2] All techniques can be combined into hybrid techniques, e.g. 2PL TO combinations [12] 9 Conclusions Both transactions and process algebra are ....

P.A. Alsberg and J.D. Day. A principle for resilient sharing of distributed resources. In 2nd International Conf. on Software Eng., San Francisco, pages 562-570, San Francisco, CA, USA, 1976.

....to mask crashes due to program bugs. Hence, a fault tolerance method based on failure detection and recovery seems more appropriate for real mobile agent systems. We presentsuch a method in this paper. Our approach has its roots in the primary backup approach for making services highly available [1, 4]. At critical points in the execution of an itinerant computation, its state is stored on a set of backups that wecallrear guards [9] If there is a failure, then one of these rear guards continues the itinerant computation. The essential differences between our approach and primary backup are: ....

....actions can be used to implement atomic transactions. The recovery action that an agent should take will most likely change when that agentmoves or spawns a new agent. Hence, both move and spawn both terminate an action. For example, Figure 1 shows a mobile agent computation originating with a1[1]. The second version of agent a1, a1[2] starts when a1[1] executes move naming host H2 and terminates by executing spawn. The spawn creates both the third version a1[3] of a1, still on H2 and the third version a2[3] of a new agent a2onH4.By convention we define a1[2] to be the second version of ....

[Article contains additional citation context not shown here]

P.A. Alsberg and J.D. Day. A principle for resilient sharing of distributed resources. In Proceedings of the Second International Conference on Software Engineering,SanFrancisco, California, USA, 13-15 October 1976, pp. 627--644.

....in determining the order in which the operations are applied at each replica. The strongest and simplest notion of consistency is atomicity, which requires the replicas to collectively emulate a single centralized object. Methods to achieve atomictry include write all read one [4] primary copy [1, 21, 18], majority consensus [22] and quorum consensus [8, 9] Because achieving atomJetty often has a high performance cost, some applications, such as directory services, are willing to tolerate some transient inconsistencies. This gives rise to different notions of consistency. Sequential consistency ....

P. Alsberg and :l. Day. A principle for resilient sharing of distributed resources. In Proceedings of the 2nd International Conference on Software Engineering, pages 627-644, Oct. 1976.

....Implementation of a Bofo Service Navin Budhiraja Keith Marzullo Fred B. Schneider Sam Toueg Department of Computer Science, Cornell University Ithaca NY 14853, USA 19 October 1991 1 Introduction One way to implement a fault tolerant service is the primary backup or primarycopy approach [1]. With this approach, a service is implemented by a collection of servers. One server is designated as the primary; the others are called backups. Clients send requests to the primary and any responses to requests come from the primary. If the primary fails, then a failover occurs after which one ....

....we must characterize the systems we are willing to consider. Unfortunately, there is no widely accepted definition of the primary backup approach. We believe that the following four attributes 1 characterize a primary backup system and note that several purported primarybackup protocols (e.g. [1,2,5,8,3]) satisfy this characterization. There are, however, purported primary backup protocols that do not satisfy one or more of these attributes (e.g. 4] pb1: There exists a state predicate PRMY on the state of any server such that PRMY is true on the state of at most one server. pb2: At each ....

[Article contains additional citation context not shown here]

P.A. Alsberg and J.D. Day. A Principle for Resilient Sharing of Distributed Resources. In Proceedings of the Second International Conference on Software Engineering, pages 627--644, October 1976.

....one server as the primary and all the others as backups. Clients make requests by sending messages only to the primary. If the primary fails, then a failover occurs and one of the backups takes over. This service architecture is commonly called the primary backup or the primary copy approach [1] and has been widely used in commercial fault tolerant systems. With both the state machine approach and the primary backup approach, the goal is to provide clients with the illusion of a service that is implemented by a single server. The Supported in part by an IBM Graduate Fellowship. ....

....1 2ffi when n 2f and f 1 2f ffi send omission n f ffi when f = 1 2ffi when f 1 2f ffi 2ffi whenf 1 Bound not known to be tight. D Gamma assumed. 6 Existing Primary Backup Protocols We now discuss some existing primary backup protocols: the Alsberg and Day protocol [1], the Tandem protocol [3] HA NFS [4] and an experimental non blocking protocol [5] 6.1 The Alsberg and Day Protocol We believe this protocol to be the earliest primary backup protocol appearing in the literature. It employs two servers and tolerates a single crash failure. In this protocol, ....

P.A. Alsberg and J.D. Day. A principle for resilient sharing of distributed resources. In Proceedings of the Second International Conference on Software Engineering, pages 627--644, October 1976.

....method based on failure detection and recovery seems the better choice when itinerant compuations must operate beyond a local area network and must employ potentially buggy software. We present such a fault tolerance method in this paper. It has roots in the primary backup approach [1, 4], only with the fixed backup processors being replaced by mobile agents called rear guards [9] With our method, a rear guard performs some recovery action and continues the itinerant computation after a failure is detected. The key differences between our approach and the primary backup approach ....

....used to implement atomic transactions. The recovery action that an agent should take will most likely be changed when that agent moves or spawns a new agent. Hence, move and spawn both are defined as terminating an action. For example, Figure 1 shows an itinerant computation originating with a1[1]. The second version of agent a1, a1[2] starts when a1[1] executes move naming host H2 and terminates by executing spawn. The spawn creates both the third version a1[3] of a1, still on H2, and the third version a2[3] of a new agent a2 (on H4) By convention, we define a1[2] to be the second ....

[Article contains additional citation context not shown here]

P. A. Alsberg and J. D. Day. A principle for resilient sharing of distributed resources. In Proceedings of the Second International Conference on Software Engineering, San Francisco, California, USA, 13-15 October 1976, pp. 627--644.

....one server as the primary and all the others as backups. Clients make requests by sending messaes only to the primary. If the primary fails, then a failover occurs and one of the backups takes over. This service architecture is commonly called the primary backup or the primary copy approach [1] and has been widely used in commercial fault tolerant systems. However, the approach has not been analyzed nearly as extensively as the state machine approach. Little is known of its costs and tradeoffs, the degree of replication required, or the worst case response time for various failure ....

....server for some values of k and A: Pb4: There exist fixed values k and A such that the service behaves like a single (k, A) bofo server. We believe that the above four properties characterize a primary backup approach and have checked that many primary backup protocols in the literature (e.g. [1, 3, 4, 7]) do satisfy this characterization. Note that Pb4 is not implementable if the number of failures (that is, the number of servers and communication components that fail) can not be bounded a priori. This is because an unbounded number of servers would be required to implement the service. In a ....

P.A. Alsberg and J.D. Day. A principle for resilient sharing of distributed resources. In Proceedings of the Second International Conference on Software Engineering, pages 627-644, October 1976.

....in determining the order in which the operations are applied at each replica. The strongest and simplest notion of consistency is atomicity, which requires the replicas to collectively emulate a single centralized object. Methods to achieve atomicity include write all read one [4] primary copy [1, 26, 23], majority consensus [27] and quorum consensus [11, 12] Because achieving atomicity often has a high performance cost, some applications, such as directory services, are willing to tolerate some transient inconsistencies. This gives rise to different notions of consistency. Sequential ....

P. Alsberg and J. Day. A principle for resilient sharing of distributed resources. In Proceedings of the 2nd International Conference on Software Engineering, pages 627--644, Oct. 1976.

.... For this reason, active replication is often considered a better choice for most real time systems, and passive replication for most other cases [32] In most computer systems, the implementation of passive replication is based on a synchronous model, or relies on some dedicated hardware device [4, 9, 15, 28, 36]. However, we consider here the context of asynchronous systems in which the detection of failures is not certain. In such systems, all implementations of passive replication that we know of are based on a group membership service and must exclude the primary whenever it is suspected to have ....

P. A. Alsberg and J. D. Day. A principle for resilient sharing of distributed resources. In Proceedings of the 2nd International Conference on Software Engineering, pages 562--570, San Francisco, CA, USA, 1976.

....continues to provide correct service even when a fraction of the replicas fail. Therefore, the system is highly available provided the replicas are not likely to fail all at the same time. The problem is that research on replication has focused on techniques that tolerate benign faults (e.g. AD76, Gif79, OL88, Lam89, LGG 91] these techniques assume components fail by stopping or by omitting some steps and may not provide correct service if a single faulty component violates this assumption. Unfortunately, this assumption is no longer valid because malicious attacks, operator ....

....is not faulty, this is the correct result of the operation. The hard problem in state machine replication is ensuring non faulty replicas execute the same requests in the same order. Like Viewstamped Replication [OL88] and Paxos [Lam89] our algorithm uses a combination of primary backup [AD76] and quorum replication [Gif79] techniques 18 to order requests. But it tolerates Byzantine faults whereas Paxos and Viewstamped replication only tolerate benign faults. In a primary backup mechanism, replicas move through a succession of configurations called views. In a view one replica is ....

[Article contains additional citation context not shown here]

P. A. Alsberg and J. D. Day. A principle for resilient sharing of distributed resources. In Proceedings of the 2nd International Conference on Software Engineering, pages 627--644, San Francisco, CA, Oct. 1976.

....the update response. If the probability of failure is still considered too high, we can do the following: a replica notifies some number of other replicas, and waits for acknowledgments, before sending the client response. Note that this solution differs from voting [11] and primary copy schemes [1, 26] in that a majority of replicas is not needed. For example, only two replicas out of five or seven might be involved in an update. However, the extra communication does mean that the availability of updates will decline and response time will increase. Finally we consider the reliability of the ....

....u.uid v.uid if u.uid R v.uid R. Of course, if only one replica could run server ordered updates, we would have an availability problem if that replica were inaccessible. To solve this problem, we allow different replicas to act as R over time. We do this by using the primary copy method [1, 27, 26] with view changes [8, 7] to mask failures. An active view always consists of a majority of replicas; one of the replicas in the view is the designated primary and the others are backups. The current primary is in charge of R s part of the timestamp as well as its own, and all server ordered ....

[Article contains additional citation context not shown here]

Alsberg P. A. and Day, J. D.. A Principle for Resilient Sharing of Distributed Resources. In Proc. of the 2nd International Conference on Software Engineering, pages 627-644. October, 1976. Also available in unpublished form as CAC Document number 202 Center for Advanced Computation University of Illinois, Urbana-Champaign, Illinois 61801 by Alsberg, Benford, Day, and Grapa.

....fault tolerance, as shown in Figure 3. The additions to the basic rollback recovery mechanism that make the LDFS fault tolerant are typed in bold; these are discussed in detail in the following sections. 3 Replication of Checkpoints File replication techniques have been studied extensively [16 19]. However, because we integrate file system fault tolerance with application fault tolerance, we are concerned with file replication only at the time of checkpointing. Furthermore, replica consistency is preserved automatically, since the replicas change only at the time of checkpointing. 3.1 ....

P.A. Alsberg and J.D. Day. A principle for resilient sharing of distributed resources. In Proceedings of the Second International Conference on Software Engineering, pages 627-- 644, October 1976

No context found.

P. Alsberg and J. Day. A principle for resilient sharing of distributed resources. In Proceeding of ICSE, 1976.

No context found.

P. A. Alsberg and J. D. Day. A principle for resilient sharing of distributed resources. In Proceedings of the 2nd international conference on Software engineering, 1976.

No context found.

P. A. Alsberg and J. D. Day, "A Principle for Resilient Sharing of Distributed Resources", Proceedings of the Second International Conference on Software Engineering, 1976.

No context found.

P. Alsberg and J. Day. A principle for resilient sharing of distributed resources. In Proceedings of the 2nd International Conference on Software Engineering, pages 562--570, Oct 1976.

No context found.

P. A. Alsberg and J. D. Day. A principle for resilient sharing of distributed resources. In ICSE, 1976.

No context found.

P. A. Alsberg and J. D. Day. A Principle for Resilient Sharing of Distributed Resources. In Proc. of the 2nd International Conference on Software Engineering, pages 562--570, San Francisco, CA, 1976.

No context found.

P. A. Alsberg and J. D. Day, "A Principle for Resilient Sharing of Distributed Resources", Proceedings of the Second International Conference on Software Engineering, 1976.

No context found.

P. Alsberg and J. Day. A principle for resilient sharing of distributed resources. In Proceeding of ICSE. IEEE Computer Society Press., 1976.

No context found.

Peter A. Alsberg and John D. Day. A principle for resilient sharing of distributed resources. In Proceedings of the 2nd international conference on Software engineering, pages 562-570. IEEE Computer Society Press, 1976.

No context found.

P. Alsberg and J. Day. A Principle for Resilient Sharing of Distributed Resources. In Proceedings of the Second International Conference on Software engineering, pages 562--570, Oct 1976.

No context found.

ALDA76 Alsberg P. A. and Day J. D., A Principle for Resilient Sharing of Distributed Resources, Proceedings of the 2 nd International Conference on Software Engineering, Oct 1976.

No context found.

P.A. Alsberg and J.D. Day, "A principle for resilient sharing of distributed resources," in IEEE 2nd International Conference on Software Engineering, San Francisco, CA, USA, 1976, pp.562-70.

First 50 documents  Next 50

Online articles have much greater impact   More about CiteSeer.IST   Add search form to your site   Submit documents   Feedback  

CiteSeer.IST - Copyright Penn State and NEC