SPREAD TOOLKIT

High performance messaging middleware

Presented by

Sayantam Dey

Vipin Mehta

What is SPREAD?

Spread is a group communication system that provides a number of messaging services to applications. These services can then be used by applications to make it easy to write full-featured reliable groupware, distributed servers, client-server applications, chat and news services, and many other networked enabled tools.

SPREAD – How it works

SPREAD is composed of 2 entities – daemons and client processes.

Daemon(s) maintain information about all processes connected to it and the presence of other daemon(s), if any.

Client processes join/leave the group or send/receive messages using the SPREAD primitives.

Basic Services

Abstraction of a group – a name represents a set of processes, all of whom receive messages sent to the group.

Multicast of messages to a group. Membership. Reliable message delivery. Ordering of messages sent to a group. Failure detection of members of group. A strong semantic model of how messages are

handled in response to group changes.

SPREAD primitives

SP_connect(): Initial call an application must make to establish a connection with a Spread daemon.

SP_disconnect(): Called when the application is finished with a connection to the Spread daemon.

SP_join(): Joins a group with the name passed as the string group. If the group does not exist among the Spread daemons it is created, otherwise the existing group with that name is joined.

SP_leave(): Leaves a group with the name passed as the string group. SP_multicast and family: SP multicast and its variants all can send a

message to one or more groups. SP_receive and SP_scat_receive: This receives data and membership

messages. Other functions for error reporting.

SPREAD architecture

Modular Design. Divided into 2 components – implementation of the network communication layer and multiple client interfaces.

Multiple link protocols supported in the network communication layer. Currently implements 3.

Ring Protocol: for low latency LANs with not more than 30 daemons.

Point to Point: stable transport over WAN. Hop: cross WAN with high latency and loss. Interfaces implemented in C, Perl and Java.

SPREAD guarantees

Native support of Extended Virtual Synchrony (EVS). Can detect network partition. Generates a ‘NETWORK’

event, which allows client processes to obtain the updated membership view.

Provides a ‘Level of Service’. This value determines the extent of ordering and

reliability of the message. The application can choose different levels for each message.

5 different levels of service implemented.

SPREAD guarantees continued…

This table shows the different levels of service and their relationship with ordering and reliability. (from the SPREAD toolkit user’s guide)

SPREAD application areas

Replicated servers Generic message bus for clusters and

distributed clusters N-way fail-over for IP addresses Collaborative tools – share data, video and

audio conferencing Distributed Shared Memory

Why use SPREAD

Powerful, but simple API. Only six basic calls are required to utilize Spread.

Spread is optimized and can handle over 8,000 1Kbytes messages a second in local area network settings.

Spread allows unicast, multicast, multi-group multicast, scatter-gather calls, and multiple query functions.

Flexible message semantics: Spread supports all levels of messaging from unreliable to agreed (also known as total order) to safe (which guarantees all daemons receive the message before any deliver it to applications), and provides complete extended virtual synchrony.

Why use SPREAD continued…

Spread handles network and machine partitions and re-merges safely and notifies applications about the current state of the group.

Cross Platform: Spread supports cross-platform operation between Unix (BSD, Linux, Solaris, Irix, AIX, Mac OS X, etc.) and Windows (2000/NT/98/95).

Spread currently has programming API's for C/C++, C#, Java, Perl, Python and Ruby.

References

www.spread.org www.cnds.jhu.edu SPREAD user guide The Spread Wide Area Group Communication

System, Yair Amir and Jonathan Stanton.