Users Guide to Spread

1 A Users Guide to SpreadVersion R. 21, 2002iiContents1 Introduction to is Spread ?.. Issues.. with reliable IP-multicast.. of services.. of Spread architecture.. Guarantees.. Information..62 Installing and Configuring Spread .. a binary distribution.. a source distribution.. Spread .. a Spread Network.. a Configuration File.. the Daemon and Clients.. the Monitor.. Spread for Performance or Unique Situations.. timeouts.. in high-load environments.. with bursty application traffic.. the number of daemons per segment..213 Spread C .. Buffer Handling.

2 Datatypes.. and family.. and SPscatreceive.. Functions..344 Spread Java .. Datatypes.. Classes.. Class.. Class.. Class.. Classes.. for Applets.. Functions..435 The Event .. and General Use.. Functions.. Events.. File Descriptors..47 Chapter 1 Introduction to What is Spread ?When designing distributed applications one must make a number of architecturalchoices. These choices include how communication between applications will behandled, what the roles of each process will be, how dependent each machine ison the others for operation of the application, etc.

3 Part of what makes creatingreliable, high-performance, useful distributed applications hard is the number offundamental choices one must make and the complex interactions between group communication model is a framework that provides both a physicaltoolkit upon which to build and a model which limits the number of choices thatmust be met. This model simplifies the task of constructing a reliable, correctdistributed application while still giving the user a powerful set of abstractionsupon which many different distributed applications can be built. It is certainlytrue that not every application can be built using the group communication model,and even if it could the negative characteristics of the model can make groupcommunications a bad choice.

4 What group communications does do, however, ismake a large number of distributed applications easier to build and more is no different than any other higher level example, one could build every network application by creating IP levelpackets by hand, having the application provide packet checksums, multiplexing,reliability, ordering, and flow control, but everyone realizes that although that isthe most powerful approach (and it is used for some specialized applications) inalmost every case you want to use a high level API like sockets and an establishednetwork protocol like basic services provided by most group communication systems of a Group (a name representing a set of processes, all of whomreceive any messages sent to the Group).

5 Of messages to a 1. INTRODUCTION TO of a messages to a of messages sent to a detection of members of the strong semantic model of how messages are handled when changes to theGroup membership should be obvious that the name Group Communications System is veryappropriate, as the concept of a Group is the fundamental abstraction of thesystem. Once you have that abstraction all the other services make sense: knowingwho is in the group, talking to the group, knowing when someone leaves the group,agreeing on an ordering of events in the are a few distinct example applications that exhibit how the group com-munication model provides a useful abstraction for a wide variety of distributedapplications.

6 Service and machine monitoring. A number of machines export their statusto groups of interested monitors. Whenever failure occurs the monitors arenotified. Collaborative tools. Many different groups of participants each want toshare data, video and audio conferencing. DSM (Distributed Shared Memory). Sending pages of memory to machineswhere it is needed using reliable multicast. Highly reliable services (such as air traffic control systems, stock exchanges,military tracking and combat control systems). Services that involve com-munication of information among numerous machines and people and havehigh requirements for both availability and fault-tolerance.

7 Replicated databases. A number of instances of a database exist in severaldifferent locations. They must all be kept synchronized in such a way that aclient can query or update any of them and the results will be the same as ifonly one copy Design Comparison with reliable IP-multicastThe service provided bySpreadand the service provided by many reliable IP-multicast protocols have some features in common and some differing seman-tics. The main area of overlap is that they both solve the problem of DESIGN ISSUES3best-effort reliability when sending multicast messages for small to medium sizedgroups.

8 The key difference is that most reliable IP-multicast protocols aim tobe also solve that problem for very large groups, whileSpreaddoes not supportvery large groups, but does provide a stronger model of reliability and additionalservice such as practical difference is that reliable IP-multicast usually relies on a widearea IP-multicast network (such as the mbone, or ISP support for multicast rout-ing) whileSpreadonly relies on point-to-point unicast IP support, and uses IP-multicast only as a performance subtle distinction between reliable IP-multicast andSpread s Reliableservice is thatSpreadintegrates a membership notification service into the streamof messages.

9 The membership notifications provide some knowledge of who ac-tually received the reliable messages. The issue of membership is a key distinctionbetween the unicast, or point-to-point world of TCP/IP and multicast services. Inmulticast it is often necessary to know with whom you are reliably communi-cating since there is no obvious other party as in Flexibility of servicesThe key question is at what level of granularity do you define services? GCSallow a number of different levels of service and the application only pays forthose that it needs (to a large degree).

10 The GCS primitives are very flexible andmany different applications can use them in different goal ofSpread(not necessarily all GCS) is to support the broad middleof applications. This includes those that need more than unreliable multicast ormulticast to millions of Users , but don t have extremely specialized needs such ashard real-time requirements, hardware fault-tolerance, or esoteric reliability andsemantic models. The ideas of GCS have been extended to some of these extremes(especially real-time and hardware assisted fault-tolerance), and have influencedto a small degree the solutions being proposed to reliable multicast to millions number of people assert that it is an accepted truth that no one system orprotocol will work for all cases.