On group communication in large-scale distributed systems

Babaoğlu, Özalp; Schiper, André

doi:10.1145/504390.504396

Cited by 18 publications

(6 citation statements)

References 12 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…The degree of scaling capability of a supporting group communication system must be commensurate with the wide-ranging scope of possible military operations world-wide. Conventional group technology is not easily scalable to very large dimensions; resulting from an inability to distinguish group membership roles and an inability to manage very dynamic structures and partitions [10]. Solutions to overcome this problem of scalability need to address the issue of geography -because even small groups can have members throughout the globe -and also the problems arising from groups as described in [10].…”

Section: Scalabilitymentioning

confidence: 99%

“…Conventional group technology is not easily scalable to very large dimensions; resulting from an inability to distinguish group membership roles and an inability to manage very dynamic structures and partitions [10]. Solutions to overcome this problem of scalability need to address the issue of geography -because even small groups can have members throughout the globe -and also the problems arising from groups as described in [10]. Additionally, as will be discussed in section 3, the popular concept of virtual synchrony has proven fragile in large scales.…”

Section: Scalabilitymentioning

confidence: 99%

“…The reasons for this effort are to overcome the less than optimal performance resulting from the Isis ability to operate only in user space. The drawbacks of an implementation in user space such as Isis are: (1) because the communication system is implemented at a non-privileged level (user space), it cannot maximize certain multicast primitives available at a lower network level; (2) resource management and buffering policies of many operating systems do not perform well when used by group communication protocols; (3) using only user space results in a higher rate of context switches [10]. The result is Horus, which in addition to being smaller and more flexible than Isis, also adds some security features and an ability to manage network partitioning.…”

Section: Horusmentioning

confidence: 99%

See 2 more Smart Citations

A survey and comparison of distributed systems for group communications suitable for network-centric warfare

2006

View full text Add to dashboard Cite

In this work we survey distributed systems that can provide group communications, including both existing commercial systems and proposed research systems. Distributed systems are compared across multiple architectural characteristics such as fault-tolerance, scalability, security, delivery guarantees, and management as well as contrasted against systems utilizing peer-to-peer systems, application-level multicast, and IP layer multicast. Comparing distributed systems which provide group communications is a step toward developing systems appropriate for military network-centric group communications where more research is needed. A secondary result is an attempt to merge group communications terminology between distributed systems, peer-to-peer, application-layer multicast and IP layer multicast.

show abstract

Section: Scalabilitymentioning

confidence: 99%

Section: Scalabilitymentioning

confidence: 99%

Section: Horusmentioning

confidence: 99%

See 1 more Smart Citation

A survey and comparison of distributed systems for group communications suitable for network-centric warfare

2006

View full text Add to dashboard Cite

show abstract

“…A server in the persistence domain for a session maintains persistent copies of the session's objects. Persistence domains are similar to the notion of a core group in [1]. However, for the sake of efficiency we are considering an architecture in which we separate the notions of group addressing and delivery guarantees.…”

Section: Delivery ~L Reliable Ii~ Messagesmentioning

confidence: 99%

A stake in cyberspace

Kindberg

1996

Proceedings of the 7th Workshop on ACM SIGOPS European Workshop: Systems Support for Worldwide Applications

View full text Add to dashboard Cite

introductionConsider the information 'terrain' in which we browse and interact over the Internet, principally the World Wide Web but also USENET, email and IRC. This differs in several basic ways from the territory that we are used to:° We can be -and often want to be -in several places at once. °The information terrain is hard to navigate. It is infinite and heterogeneous. There are only rudimentary maps. It is in a state of flux, and is not sharply distinguished from the artefacts it sustains.• Currently we spend most of our time wandering alone where there is much evidence of human activity, but where the natives themselves and their tools are nowhere to be seen. When we do encounter others, we pass low-bandwidth messages back and forth, often knowing little about our interlocutors.The thesis of this position paper is:o The most useful notion of the terrain is the combination of users and the shared information that they interact with, not the information alone.• Information is where users should be able to encounter other users with similar interests. We need to support collaboration and other forms of social interaction between users, who either meet while browsing information or who are already members of a group..The key to collaborative information sharing and interaction on the Internet is the concept of boundary, which encompasses naming, security and integrity of shared data, and user communication and awareness. The navigation problem will not go away, but boundaries enable us to impose structure on the sprawl.We now present an early snapshot of a design that addresses these points. A framework for sharing objects across the InternetMushroom l [10] is a framework for collaboration and interaction across the Internet. This framework supports the dynamic creation and management of Mrooms, which are environments for collaborative activity and containers for shared objects. We give an overview of the users' model in this section, and go on to describe the system issues in the next section.Although we base our work on a 'room' metaphor [6,9], we recognise the need to provide a task-based representation of Mrooms. Users access Mrooms through links on World Wide Web pages, and they navigate between them by following links; however, access control is applied. In Mrooms, users can share applications and information objects such as documents, multimedia presentations and whiteboards. Users also share tools for awareness of and communication with other users in the Mroom. Mrooms are persistent, and users can either interact and communicate synchronously (in the same Mroom at the same time) or asynchronously (users occupy the Mroom at different times, but observe one another's changes to information objects). Objects within Mrooms may be active. For example, in distance-learning a lecturer may create interactive objects for student experiments. Equally, we can use Mrooms to store conventional objects such as PostScript files and word processing documents.

show abstract

“…A group-oriented approach has been successful in providing this support. One such approach is Virtual Synchrony (VS), also known as View Synchrony [1,2,3]. As the Internet grows, and large numbers of computers can collaborate to perform tasks, the use of the VS model in large groups and in worldwide applications is becoming more important.…”

Section: Introductionmentioning

confidence: 99%

Structured virtual synchrony

Guo

Vogels

Renesse

1996

Proceedings of the 7th Workshop on ACM SIGOPS European Workshop: Systems Support for Worldwide Applications

View full text Add to dashboard Cite

Multipoint communication protocols that offer group membership and virtually synchronous message delivery are commonly believed to be heavyweight and non-scalable. To meet the needs of large-scale computer-supported collaborative work, distributed parallel computing, and future worldwide applications, we designed the Structured Virtual Synchrony (SVS) protocol. The protocol has been implemented as part of Horus, a group communication system developed at Cornell University. It scales up to 800 members, while achieving a one-way latency of 100 milliseconds over groups of 500 members.

show abstract

On group communication in large-scale distributed systems

Cited by 18 publications

References 12 publications

A survey and comparison of distributed systems for group communications suitable for network-centric warfare

A survey and comparison of distributed systems for group communications suitable for network-centric warfare

A stake in cyberspace

Structured virtual synchrony

Contact Info

Product

Resources

About