About: Gbcast is a research topic. Over the lifetime, 45 publications have been published within this topic receiving 2541 citations. The topic is also known as: group broadcast.
TL;DR: Fault-tolerant consensus protocols are given for various cases of partial synchrony and various fault models that allow partially synchronous processors to reach some approximately common notion of time.
Abstract: The concept of partial synchrony in a distributed system is introduced. Partial synchrony lies between the cases of a synchronous system and an asynchronous system. In a synchronous system, there is a known fixed upper bound D on the time required for a message to be sent from one processor to another and a known fixed upper bound P on the relative speeds of different processors. In an asynchronous system no fixed upper bounds D and P exist. In one version of partial synchrony, fixed bounds D and P exist, but they are not known a priori. The problem is to design protocols that work correctly in the partially synchronous system regardless of the actual values of the bounds D and P. In another version of partial synchrony, the bounds are known, but are only guaranteed to hold starting at some unknown time T, and protocols must be designed to work correctly regardless of when time T occurs. Fault-tolerant consensus protocols are given for various cases of partial synchrony and various fault models. Lower bounds that show in most cases that our protocols are optimal with respect to the number of faults tolerated are also given. Our consensus protocols for partially synchronous processors use new protocols for fault-tolerant “distributed clocks” that allow partially synchronous processors to reach some approximately common notion of time.
TL;DR: A simple and efficient layer two virtual network tool that in effect connects the virtual machine to the home network of the user, making the connectivity problem identical to that faced by the user when connecting any new machine to his own network.
Abstract: Virtual machines can greatly simplify wide-area distributed computing by lowering the level of abstraction to the benefit of both resource providers and users. Networking, however, can be a challenge because remote sites are loath to provide connectivity to any machine attached to the site network by outsiders. In response, we have developed a simple and efficient layer two virtual network tool that in effect connects the virtual machine to the home network of the user, making the connectivity problem identical to that faced by the user when connecting any new machine to his own network. We describe this tool and evaluate its performance in LAN and WAN environments. Next, we describe our plans to enhance it to become an adaptive virtual network that will dynamically modify its topology and routing rules in response to the offered traffic load of the virtual machines it supports and to the load of the underlying network. We formalize the adaptation problem induced by this scheme and take initial steps to solving it. The virtual network will also be able to use underlying resource reservation mechanisms on behalf of virtual machines. Both adaptation and reservation will work with existing, unmodified applications and operating systems.
TL;DR: This paper presents two variants of virtual synchrony, which are supported by Horus, and shows that in order to support this property, the application program has to block messages during view changes.
Abstract: This paper presents two variants of virtual synchrony, which are supported by Horus. The first variant, called strong virtual synchrony, includes the property that every message is delivered within the view in which it is sent. This property is very useful in developing applications, since it helps in minimizing the amount of context information that needs to be sent on messages, and the amount of computation which is required in order to process a message. However, it is shown that in order to support this property, the application program has to block messages during view changes. An alternative definition, called weak virtual synchrony, which can be implemented without blocking messages, is then presented. This definition still guarantees that messages will be delivered within the view in which they were sent, only that it uses a slightly weaker notion of what the view in which a message was sent is. An implementation of weak virtual synchrony that does not block messages during view changes as also developed in this paper.
TL;DR: In this paper, an intercept function is implemented as a comparator, switch or router, arranged to intercept a status message from one of the virtual machines, or applications run by that virtual machine.
Abstract: A data center can share processing resources using virtual networks. A hosting program 9,10 hosts one or more virtual machines 11, 12 . The program has a virtual interface VIF 1 14 , to the virtual machines, a network interface 19 to enable communication between the virtual machines and other nodes of a network, and an infrastructure management interface 8 , invisible to the virtual machines. The program has an intercept function 7 implemented as a comparator, switch or router, arranged to intercept a status message from one of the virtual machines, or applications run by that virtual machine. The status indication is sent to a status buffer 5 and is made available to the infrastructure management interface without providing a network path between the management interface and the virtual machine. This can discriminate between VM failure and communication failure, and the invisibility maintains isolation and helps avoid vulnerability to denial of service attack.
TL;DR: The Object Group pattern supports the implementation of replicated objects, of load sharing, and of efficient multicast communication over protocols such as IP-multicast or UDP-broadcast, and has been implemented in the Electra and in the Orbix+Isis CORBA Object Request Broker.
Abstract: This paper describes "Object Group", an object behavioral pattern for group communication and fault-tolerance in distributed systems. The Object Group pattern supports the implementation of replicated objects, of load sharing, and of efficient multicast communication over protocols such as IP-multicast or UDP-broadcast. Application areas of the pattern are fault-tolerant client/server systems, groupware and parallel text retrieval engines. Events within an Object Group honor the Virtual Synchrony model. With Virtual Synchrony, the size of an object group can be varied at run-time while client applications are interacting with the group. A replicated state remains consistent in spite of objects entering and leaving the group dynamically and in spite of failures. The Object Group pattern has been implemented in the Electra and in the Orbix+Isis CORBA Object Request Broker.