David R. Cheriton and Willy Zwaenepoel. Distributed Process Groups in the V Kernel. ACM Transactions on Computer Systems, Vol. 3, No. 2, ACM, May 1985, 77-107.  Home/Search   Document Not in Database   Summary   Related Articles   Check

....using a single group address can provide transparency, greater efficiency, and concurrency. Many applications are natural candidates for using multicast, e.g. distributed databases [1] replicated file systems [2] resource allocation in distributed systems [3] distributed process management [4], distributed games [5] replicated procedure calls [6] and teleconferencing [7] Most existing multicast services (and much of the research) has concentrated on local area networks (LANs) 1] 4] 8] 10] since these provide a broadcast medium, simplifying Manuscript received September 22, ....

.... file systems [2] resource allocation in distributed systems [3] distributed process management [4] distributed games [5] replicated procedure calls [6] and teleconferencing [7] Most existing multicast services (and much of the research) has concentrated on local area networks (LANs) 1] [4], 8] 10] since these provide a broadcast medium, simplifying Manuscript received September 22, 1994; revised September 15, 1995; approved by IEEE ACM TRANSACTIONS ON NETWORKING Editor D. Estrin. Note from the Editor in Chief: This paper was originally submitted in 1994 and accepted in 1996. ....

[Article contains additional citation context not shown here]

D. Cheriton and W. Zwaenepoel, "Distributed process groups in the V-kernel," ACM Trans. Comput. Syst., vol. 3, no. 2, pp. 77--107, May 1985.

....dynamic. Static replication means that the number and the identity of the copies do not change during the lifetime of the replicated object. Dynamic replication is more powerful since copies may be added or removed at runtime. 2. 3 Group Communication Groups were first introduced in the V Kernel [CZ85] as a convenient addressing mechanism. They were later extended to handle replication in the Isis system [Bir93] The key idea of group communication is to gather a set of processes or objects into a logical group, and to provide primitives for sending messages to all group members at the same ....

D.R. Cheriton and W. Zwaenepoel. Distributed process groups in the V kernel. ACM Transactions on Computer Systems, 3(2):77--107, May 1985.

....routers is not a bottleneck. 5. Overview of Related Work There has been a significant amount of research on reliable multicast protocols. The early work has focused on distributed systems, providing primitives for constructing distributed applications, such as the ISIS system[30] and the V kernel[31]. Other early work has focused on local area networks or broadcast links [32, 33, 34, 35] A good survey of the early work can be found in [27] Here we focus on recent work on reliable multicast that aims to provide scalability to very large groups. The vast majority of recent reliable multicast ....

Cheriton, D., Zwaenepoel, W., "Distributed Process Groups in the V kernel", ACM Transactions on Computer Systems, 3(2):77-107, May 1985.

....schedulers. Several distributed operating systems have responded to this trend by incorporating group communication mechanisms directly into the communication subsystem, in addition to more standard RPC IPC interfaces and message streams (e.g. Amoeba [KTFHB89] Chorus [RAA 88] and V [CZ85] Implementing communication primitives (of any kind) at a low level of the operating system usually results in better performance due to a decrease in context switches and cross address space references, such as demonstrated by the 1 Amoeba operating system [vRvST89] However, such an approach ....

David Cheriton and Willy Zwaenepoel. Distributed process groups in the V kernel. ACM Transactions on Computer Systems, 3(2):77--

.... Client server interactions can be implemented by two di erent mechanisms: in closed loop, that is, in a blocking, request con rmation manner, usually performed through RPC [14] or in open loop, that is, in an unblocking manner, usually performed through group communication, pioneered by Cheriton [27], Birman [16] and Cristian [28] and followed by many others. From previous works [17, 55] it is known to be dicult to scale service access when clients need to be strongly coupled (for instance, when all messages need to be ordered) However, there are a number of services, especially in ....

D. Cheriton and W. Zwaenepoel. Distributed process groups in v-kernel. ACM Transactions on Computer Systems, 3(2):77-107, 1985.

....formally for the first time and contributed several protocols for the environment. It has also refined the virtual synchrony execution model substantially. Current work is looking at multiplexing several applications onto a single but application customized protocol stack. The V System [11] was arguably the first system that made use of the concept of process groups. It was a micro kernel meant specifically for distributed environments. While the system did not bother itself with providing reliability guarantees, it used process groups for service replication at multiple locations ....

D. Cheriton and W. Zwaenwpoel, "Distributed Process Groups in the V Kernel," ACM Transactions on Computer Systems, pp. 77--107, May 1985.

....(NACKs) slotting, and damping. To ensure forward progress of the sender, each receiver periodically sends a positive acknowledgment (ACK) However, ACKs are only required if there are no errors (i.e. NACKs implicitly acknowledge correctly received messages. Crowcroft [30] and Cheriton [23, 24, 22] study LAN based client server applications 2 . In Crowcroft s protocol, the client maintains send and receive windows for each server in 2 In the client server domain, the servers make up the multicast group. 2.3. Real Time Multicast Protocols 14 the group. The minimum of the send windows ....

D. R. Cheriton and W. Zwaenepoel. Distributed Process Groups in the V Kernel. ACM Transactions on Computer Systems, 3(2):77--107, May 1985.

.... pull form transactions, for encapsulation of multiple actions Client server interactions can be implemented by two different mechanisms: in closed loop, usually performed through RPC [Birrell Nelson 1984] or in open loop, usually performed through group communication, pioneered by Cheriton [Cheriton Zwaenepoel 1985], Birman [Birman Joseph 1987] and Cristian [Cristian et al. 1985] and followed by many others. From previous works [Birman et al. 1991] Ladin et al. 1990] it is known to be difficult to scale service access when clients need to be strongly coupled (for instance, when all messages need to be ....

D. Cheriton and W. Zwaenepoel, "Distributed Process Groups in the V-Kernel", ACM Transactions on Computer Systems, 3 (2), pp.77-107, 1985.

....The problem is that the operating systems only offer a single process abstraction. More flexible process abstractions make sharing of resources such as memory and files efficient and easy. For instance, some operating systems support multiple threads of control within a single address space [23, 41]. Powerful remote communication primitives can also support adaptability. For instance, efficient multicast encourages the development of applications that can be spread among hosts in many different ways. Using logical multicast addresses the application does not have to worry about the location ....

....in many different ways. Using logical multicast addresses the application does not have to worry about the location of the destination. Servers can relocate without informing their clients. Service requests directed to the logical address can be answered by any of a group of replicated servers [23]. New languages also offer support for adaptability. Object oriented languages provide data abstraction to clearly define the interface to the programmer. Furthermore, the syntax and semantics of object references are the same whether the message is to an object in the same address space, in a ....

David. R. Cheriton and W. Zwaenepoel. Distributed process groups in the V kernel. ACM Transactions on Computer Systems, 3(2):77--107, May 1985.

.... distribution, 3) many to one communication, where several transmitters send to one receiver, useful for error logging and monitoring, and 4) many to many communication, where all clients send to and receive from one another, useful for video conference calls and distributed processing applications [5]. In order to compare the strengths and weaknesses of VP and VC connections in supporting these types of communication, we first define some terminology. We define an ATM network connection to be a single end to end VP or VC connection created by the network, usually as a result of a signaling ....

....so that the resulting probability of incorrect VCI selection is acceptably low. Recovery procedures can be also added for when two clients choose the same VCI. Note that this scheme for selecting identifiers using timeouts is very similar to that used in the V system for creating new groups [5]. The problem of which VCI to use for the initial negotiation can be solved by establishing a well known signaling VCI. In this way, the negotiations do not conflict with other traffic. On the signaling VCI, per frame identifiers can be used to distinguish transmitters on this logical channel, as ....

D.R. Cheriton and W. Zwaenepoel, "Distributed Process Groups in the V Kernel." ACM Transactions on Computer Systems, 3(2):77-107, May 1985.

....To avoid this problem, our applications do not construct cyclic flows. For instance, the Teleconf play and record objects are separate to avoid creating a false cycle. None of these problems would exist in an operating system that supports multiple threads of control in each address space [CZ85, Ras86] The fourth problem is that callback methods must be statically bound. For instance, when an object asks a SuiteSound record object to issue periodic callbacks, the name of the callback method is fixed at compile time. We work around this problem by using fixed names for callback ....

David. R. Cheriton and W. Zwaenepoel. Distributed process groups in the V kernel. TOCS, 3(2):77--107, May 1985.

....one to one protocols that have be augmented to support one to many (multicast) communication. Consider, for example, a simple message transaction in which a client sends a request message to a collection of servers, and one or more of the servers receive the request and sends a reply message [8]. Because Psync distributes all messages to all participants, the servers will receive each others reply messages. In contrast, only the client receives the reply messages in the case of a multicast. The former mechanism is desirable if a server is able to avoid doing unnecessary work because it ....

....messages. The interesting aspect of this blast mechanism is that it is encapsulated as a distinct protocol rather than embedded in Psync [1] 7 Related Work Recent work on interprocess communication has explored several dimensions of the problem space, including support for group communication [8], the exchange of very large messages [9,29] alternative send receive semantics [6] guaranteeing a consistent order on message delivery in a manyto many communication [3,4] and techniques for logging messages so as to facilitate recovery from processor failure [15,16,22,24,25] The work ....

D. Cheriton and W. Zwaenepoel. Distributed process groups in the V kernel. ACM Trans. on Computer Systems 3, 2 (May 1985), 77-107.

No context found.

D.R. Cheriton and W. Zwaenepoel, "Distributed Process Groups in the V Kernel", ACM Trans. on Computer Systems 3(2), May, 1985.

No context found.

D. R. Cheriton and W. Zwaenepoel. Distributed Process Groups in the V Kernel. ACM Transactions on Computer Systems 3(3), May, 1985.

No context found.

David R. Cheriton and Willy Zwaenepoel. Distributed Process Groups in the V Kernel. ACM Transactions on Computer Systems, Vol. 3, No. 2, ACM, May 1985, 77-107.

No context found.

D. Cheriton and W. Zwaenepoel, "Distributed process groups in the V kernel," ACM Trans. Comput. Syst., vol. 3, no. 2, pp. 77--107, May 1985.

No context found.

D. Cheriton and W. Zwaenepoel, "Distributed process groups in the V kernel," ACM Transactions on Computer Systems, vol. 3, no. 2, pp. 77--107, 1985.

No context found.

D.R. Cheriton, W. Zwaenepoel, \Distributed Process Groups in the V Kernel", ACM Trans. on Comp. Syst., vol. 3 no. 2 (May 85).

No context found.

17 D. R. Cheriton and W. Zwaenepoel. Distributed Process Groups in the V Kernel. ACM Trans. on Computer Systems, 2(3):77--107, May 1985.

No context found.

David Cheriton and Willy Zwaenepoel. Distributed process groups in the V kernel. ACM Transactions on Computer Systems, 3(2):77--107, May 1985.

No context found.

D. R. Cheriton and W. Zwaenepoel, "Distributed process groups in the V kernel," ACM Transactions on Computer Systems (TOCS), vol. 3, no. 2, pp. 77--107, May 1985.

No context found.

D. R. Cheriton and W. Zwaenpoel, `Distributed process groups in the V Kernel', ACM TOCS, 3, (2), 77--107 (1985).

No context found.

D. R. Cheriton and W. Zwaenepoel, `Distributed process groups in the V-kernel', ACM Trans. on Computer Systems, 3, (2), 77--107 (1985).

No context found.

David R. Cheriton and Willy Zwaenepoel. Distributed process groups in the V kernel. TOCS, 3(2):77-107, May, 1985.

No context found.

Cheriton, D.R. and W. Zwaenepoel. Distributed Process Groups in the V Kernel. ACM Transactions on Computer Systems 3, 2 (May) 1985, 77-107.

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