CSE298 CSE300 GCS-1.1 Group Communication Joshua A. Boggis, Richard C. Gronback, Harry L. Sauers, Adam P. Uccello Computer Science & Engineering The University

CSE298

CSE300

GCS-1.1

Group CommunicationGroup Communication

Joshua A. Boggis, Richard C. Gronback,Harry L. Sauers, Adam P. Uccello

Computer Science & EngineeringThe University of Connecticut

CSE298/300 - Distributed Object ComputingMay 1, 1999

CSE298

CSE300

GCS-1.2

Topical OverviewTopical Overview

IntroductionIntroduction Group Communication Services (GCS) Group Communication Services (GCS)

OverviewOverview Object Groups and JavaObject Groups and Java Java Shared Data Toolkit (JSDT) and Java Shared Data Toolkit (JSDT) and

Group CommunicationGroup Communication Application Proposal: Collaborative Application Proposal: Collaborative

CRCTool using JSDTCRCTool using JSDT ConclusionsConclusions ReferencesReferences

CSE298

CSE300

GCS-1.3

IntroductionIntroduction

Group Communication is complex, with Group Communication is complex, with some problems proven to be some problems proven to be impossibleimpossible to solve.to solve.

““Best Effort” principle commonplace in Best Effort” principle commonplace in computing (e.g. Internet Protocol) and computing (e.g. Internet Protocol) and extended to GCSs.extended to GCSs.

Many Unix-based systems initially Many Unix-based systems initially developed and are important to current developed and are important to current developments.developments.

A natural spill-over of OO programming A natural spill-over of OO programming methodologies has occurred in GCS methodologies has occurred in GCS research, leading to object groups, research, leading to object groups, many of which exploit feature of the many of which exploit feature of the Java programming language.Java programming language.

CSE298

CSE300

GCS-1.4

Introduction Introduction (cont’d)(cont’d)

JavaSoft has developed the JSDT, a JavaSoft has developed the JSDT, a reliable, multicast, group reliable, multicast, group communications tool for development in communications tool for development in a distributed environment.a distributed environment.

Using JSDT, why not extend a current Java Using JSDT, why not extend a current Java application for authoring CRC cards to the Group application for authoring CRC cards to the Group Communications paradigm?Communications paradigm?

CSE298

CSE300

GCS-1.5

GCS OverviewGCS Overview

Virtual Synchrony and Extended Virtual Virtual Synchrony and Extended Virtual SynchronySynchrony Virtual Synchrony orders group membership changes

with regular messages. Ensures two things: Failures don’t lead to incomplete multicast

message delivery or holes in the causal delivery order.

If two processes proceed together from one membership “view” to the next, they deliver the same messages in the first view.

Extended Virtual Synchrony needed in partitionable models: those in which a process can fail and recover those in which a network can partition & remerge

CSE298

CSE300

GCS-1.6


Extended Virtual Synchrony maintains consistent message ordering even in partitionable models.

Additionally, if a process may not have received a message, so other processes are told which processes are know to have received it.

The State Transfer ProblemThe State Transfer Problem If a whiteboard program has many members

and due to one type of system failure or another a smaller group (partition) is detached from the larger (primary partition), there should be some way to update the application so that it can continue as a whole upon subsequent recombination.

CSE298

CSE300

GCS-1.7


A solution to this recombination will vary according to the application’s requirements, however all solutions are ones that deal with the problem of state transfer.

The key is in the development of a protocol that will allow for the partitioning of a group and its successful, coherent recombination.

Ideally, this solution needs to be efficient, which excludes such solutions as every member broadcasting its state whenever a change in the group is detected.

Only those members without the new state need to be updated.

CSE298

CSE300

GCS-1.8

State Transfer ProblemState Transfer Problem

Network Partitions

Partitions ContinueIndependently

Partitions Merge

CSE298

CSE300

GCS-1.9

GCS Overview - Main ComponentsGCS Overview - Main Components

MembershipService

Message OrderingServiceMulticast

Service

CSE298

CSE300

GCS-1.10

GCS Overview - GCS Overview - Membership ServiceMembership Service

It is the membership view, mentioned earlier, that allows for a process to know what other processes it is able to communicate with at a particular time.

A membership service can either be partitionable or only allow for an active primary partition.

Basic membership service requirements are outlined below, with the last four being more advanced requirements:

CSE298

CSE300

GCS-1.11


Valid Execution Requirement This is a basic requirement and is obvious:

a process must be in a certain view, where it executes events of that view.

Self-Inclusion This will preclude a process from installing

a view of which it is not a member. Again, this should be obvious; a view is a list of processes with which the installing member should be able to communicate, which includes itself.

CSE298

CSE300

GCS-1.12


Local Monotony When keeping track of which views it is a

member of, a process identifies each view with an indicator that is monotonically increasing.

This requirement will facilitate the recovery of synchrony among processes, as their views will be installed in the same order.

Termination of Membership In order to prevent a process from waiting

forever for a message from another, a process needs to be able to install a next view.

This will allow for a process to continue, not waiting for messages from a process that may not have installed that view.

CSE298

CSE300

GCS-1.13

GCS Overview GCS Overview - Membership Service

Agreement on Membership Processes should all be in agreement on the

next common view. Therefore, a process should only install a view after it is reasonably sure that the other processes in the current view will be installing the new view.

Transitional Set Expanding upon agreement on membership,

in order to exploit the true benefits of virtual synchrony, a process needs more information than just a list of what other processes are part of a view.

Thus, a transitional set represents this additional information that is provided along with the view message.

More under the virtual synchrony requirement of the multicast service.

CSE298

CSE300

GCS-1.14


Causal Monotony of Views The unique view identifier reflects the ‘causal’

order of events in the system. When two processes reconnect, they can exploit

this property to find out which process is more updated.

Preciseness Limited by the nature of the underlying

network, it is desirable for the membership service to as accurately reflect the existing condition of the group as possible.

To be precise, the membership is required to achieve some level of completeness and accuracy, where one is usually sacrificed due to practical necessity in achieving the other.

An external failure detector may be utilized in order to convey to a process that another process may have failed.

CSE298

CSE300

GCS-1.15

GCS Overview - GCS Overview - Multicast ServiceMulticast Service

If the membership service represents the group in GCS, then the multicast service represents the communication.

As many existing network technologies employ one form of multicast service or another, it is up to a GCS to manage such ability to provide for the existence of coherent groups.

The need for high reliability, strict ordering and performance of a GCS may not coincide with the network’s ability to deliver its QoS, if defined.

Below is a listing of some of the basic and advanced requirements that a multicast service should provide:

CSE298

CSE300

GCS-1.16


Delivery Integrity A GCS should never spontaneously generate

a message. This is a rather trivial requirement as it was essentially covered by the assumption that the underlying network would not do so.

No Duplication Messages are not duplicated by the GCS.

This does not restrict the underlying network from duplicating messages, however.

Termination of Delivery A blocking of messages by the membership

protocol may be terminated. This simply states that messages will eventually be delivered, although due to the nature of asynchronous networks, there is no strict limit on the time, or latency, of delivery.

CSE298

CSE300

GCS-1.17


Same View Delivery A message must be delivered in the same

view at every process that delivers it. Virtual Synchrony

If two processes participate in the same two consecutive views, then they receive the same set of messages in the former.

In order to accomplish the condition of a process knowing which of the members of a previous view will be continuing to the next, the aforementioned transitional set is utilized.

This concept is generally included in Extended Virtual Synchrony model, currently employed in many modern GCSs.

CSE298

CSE300

GCS-1.18


Synchronous Delivery – Same View as Sending Every message is to be delivered in the view

in which it was sent. This may require the GCS to “block the

sending and delivery of messages while a membership change is taking place” [17].

GCSs that incorporate this requirement are generally said to support Strong Virtual Synchrony.

Self-Delivery Each message is delivered at least to its

sender. Prevents processes from arbitrarily discarding

left-over messages upon view changes.

CSE298

CSE300

GCS-1.19

GCS Overview - GCS Overview - Message Ordering Message Ordering ServiceService

The following outline some of the possible QoS levels that may be implemented in a GCS.

As the multicast requirements above illustrate, there are many options in the delivery of multicast messages. Of the most important are reliability and ordering.

In order to provide a consistent group view, the order of the delivery of messages is important in the design of a GCS.

Below is a list of some basic requirements that a GCS should support in its messaging ordering service:

CSE298

CSE300

GCS-1.20


FIFO Delivery This QoS type guarantees that messages

from the same sender do not arrive out of order.

This would represent the lowest, most basic level in the QoS ordering hierarchy.

Casual Delivery This is an extension of FIFO, requiring that a

response to a message is always delivered after the delivery of the original message.

Strong Agreed Delivery This requirement guarantees that messages

are delivered in the same order everywhere. With this method, processes must agree upon the order of messaged, even if they become disconnected.

CSE298

CSE300

GCS-1.21


Weak Agreed Delivery This guarantees that processes that remain

connected deliver messages in the same order.

This method corresponds to strong agreed delivery unless there is a link failure.

Reliable FIFO, Casual, and Agreed These reliable versions guarantee that the

order is continuous within each view, in addition to the order among messages that are delivered.

CSE298

CSE300

GCS-1.22

RELIABLE AGREED

STRONG AGREED

WEAK AGREED

RELIABLE CAUSAL

CAUSALRELIABLE FIFO

FIFO

Message Ordering QoS HierarchyMessage Ordering QoS Hierarchy

CSE298

CSE300

GCS-1.23

Typical GCS ArchitectureTypical GCS Architecture

Application

Group Communication System

Failure Detector

Network

safe indication

apprecv

view change

app send

suspectrecv

net recvnet send

CSE298

CSE300

GCS-1.24

GCS Overview GCS Overview - TransisTransis

A transport-level GCS that focuses on fault-tolerant, partitionable group services in large-scale environments.

Developed at the Hebrew University of Jerusalem, Transis exploits the underlying network structure in its implementation and has produced a partitionable operation methodology that has been adopted in both the Horus and Totem systems.

Transis has extended the virtual synchrony model to partitionable systems in such a way as to provide a coherent system behavior to the application developer.

CSE298

CSE300

GCS-1.25

Transis System Model StructureTransis System Model Structure

Safe

Agreed

Causal

FIFO

GroupModule

Application

Network

Transis

send messages message deliverygroup status

CSE298

CSE300

GCS-1.26

GCS Overview - GCS Overview - TransisTransis Membership Membership ServiceService

Transis employs a Group Manager to coordinate the group messages and views among its members.

The local view is maintained by each member, which contains a list of currently connected members of the view.

As each view has a lifetime, it may undergo changes which are indicated by a view change event to each member.

Transis also uses hidden views to aid in the detection of a condition where a “view has failed to form but may have succeeded to form at another part of the system” [4].

Each member in the group holds a positive integer, which has been agreed upon by all members of the view based on local counters, to indicate uniqueness of the view.

Transis is complete in that it will ultimately exclude a slow process as having failed.

CSE298

CSE300

GCS-1.27

GCS Overview GCS Overview - - TransisTransis Multicast Multicast ServiceService

Transis provides filtering at gateways through a hierarchical communication structure, thereby preventing the flooding of the WAN with local message traffic.

Transis employs the sliding window flow control method and allows for ACKs to piggyback regular message traffic.

Message retransmission depends upon the receipt of a NACK, which is explicitly sent.

A periodic “I am alive” message is sent to preclude a process from being excluded.

Fast cluster communication is achieved with Transis by exploiting the existing network reliable multicast, “derived from the Trans protocol, that employs the Deering IP-multicast mechanism for disseminating messages using selective hardware-multicast” [4].

CSE298

CSE300

GCS-1.28

GCS Overview - GCS Overview - TransisTransis Message Ordering Message Ordering ServiceService

Depending upon the requirements of the application, Transis multicasts messages to members of a group in one of many methods: FIFO, causal, agreed and safe. FIFO multicast guarantees sender-based FIFO

delivery order. Causal multicast preserves the potential causal

order among messages. Agreed multicast enforces a unique order among

every pair of messages in all of their destinations. Safe multicast guarantees a unique order of

message delivery, and in addition, delays message delivery until the message is acknowledged by the transport layers in all of the machines in the group, thus guaranteeing delivery atomicity in case of communication failures.

CSE298

CSE300

GCS-1.29

GCS Overview - GCS Overview - TransisTransis Message Ordering Message Ordering ServiceService

With Transis, it is possible to develop large-scale WAN applications that do not depend on a primary partition to remain in operation.

By using underlying technologies, Transis is able to exploit existing networking features to achieve its goals.

As Transis is available for Unix systems as an API written in C, the need for a platform independent equivalent that incorporates the use of higher-level building blocks is clear.

The focus of Transis’ development has been on a partitionable membership service, whereas Totem focuses on fault tolerance and real-time performance.

CSE298

CSE300

GCS-1.30

GCS Overview - GCS Overview - TotemTotem

The Totem system was developed using the C programming language at the University of California, Santa Barbara.

Totem “provides reliable, totally ordered multicasting of messages over local-area networks (LANs) and exploits the hardware broadcasts of such networks to achieve high performance” [6].

It is the goal of its designers for Totem to provide a solid GCS, upon which fault tolerant and real-time performance dependent applications can be built.

CSE298

CSE300

GCS-1.31

Totem System HierarchyTotem System Hierarchy

Application Layer

Process Group Interface

Multiple-Ring Protocol

Single-Ring Protocol

Physical Medium

Best Effort Multicast

Timeouts and absence of messages

Locally ordered reliable

multicast

Globally ordered reliable

multicast

Ordered multicast to

process group

Local configuration

changes

Network topology changes

Process group membership

changes

CSE298

CSE300

GCS-1.32

GCS Overview - GCS Overview - TotemTotem Membership Membership ServiceService

Totem provides a token-based, partitionable membership service.

At its lowest level, Totem superimposes a ring topology on the underlying network. A token is circulated around this ring in a point-to-point fashion.

Only a processor holding the token can transmit a message, while a token retransmission facility is provided to allow for a lost token.

A token includes a ring (view) identifier in addition to a monotonically increasing sequence (seq) identifier and timestamp.

The single-ring protocol incorporates a membership or configuration service that allows for addition of new or rejoining members, and additionally can detect faulty members via a timeout mechanism.

CSE298

CSE300

GCS-1.33

The Totem Token (Single-Ring) The Totem Token (Single-Ring) ProtocolProtocol

Totem Token

Processorp Process

orq

Processorr

Processors

Processort

ring id

timestamp

seq aru

flow control

backlog

retransmission request list

CSE298

CSE300

GCS-1.34

GCS Overview - GCS Overview - TotemTotem Membership Membership ServiceService

The protocol attempts to form as large a membership as possible through consensus and termination: Consensus ensures every member in a configuration

agrees on the membership of that configuration. Termination ensures “every processor installs some

configuration with an agreed membership within a bounded time unless it fails within that time” [6].

This is possible through Totem’s use of an unreliable failure detector, which must exclude some slow processes, as they are indistinguishable from failed ones.

With a change in membership detected, the membership protocol constructs a new ring and reaches a new consensus.

Two Configuration Change messages are then sent out to ensure an accurate transition from old to new configuration is achieved.

CSE298

CSE300

GCS-1.35

GCS Overview - GCS Overview - TotemTotem Multicast Service Multicast Service

Totem satisfies the requirements of the transitional view and extended virtual synchrony, in additional to the less stringent requirements that all GCSs fulfill.

Totem builds upon a best-effort multicast service, using the User Datagram Protocol (UDP) in order to exploit the increased performance of hardware broadcasts on the LAN.

The single-ring layer at the bottom of the Totem hierarchy extends this best-effort multicast by providing a “service of reliable totally ordered delivery of messages on a single LAN while providing fault detection, recovery, and configuration-change services” [6].

Above the single-ring protocol lies the multiple-ring protocol which is then able to ensure global totally ordered messages.

CSE298

CSE300

GCS-1.36

GCS Overview - GCS Overview - TotemTotem Message Ordering Message Ordering ServiceService

Totem employs two message-ordering services: agreed and safe. Agreed delivery guarantees that, when a

processor delivers a message, it has already delivered all prior messages originated by processors in its current configuration and timestamped within the duration of that configuration.

Safe delivery further guarantees that before a processor delivers a message, it has determined that every other processor in its current configuration has received the message. Safe delivery is useful, for example, in transaction

processing systems where a transaction must be committed by all of the processors or none of them.

CSE298

CSE300

GCS-1.37


These services fall within the normal extended virtual synchrony requirements, which require born-ordered messages.

Born-ordered messages ensure “that the relative order of any two messages is determined directly from the messages, as broadcast by their sources” [6].

Within the token, as mentioned above, is a seq field. This field provides for the sequential numbering of all messages within a ring.

When a message is broadcast by the process possessing the token, it increments seq in the token and assigns the message this sequence number.

CSE298

CSE300

GCS-1.38


Other processes are able to detect gaps in the messages it receives and may request the retransmission of certain messages.

The retransmission request list for messages is also within the token.

If a process has received all of the messages up to the current, it accepts it as agreed.

The all-received-upto (aru) field in the token will indicate the receipt status of all processes with respect to message delivery.

If a process has a message with a sequence number equal or less than aru, it can deliver it as safe, and reclaim its buffer space.

CSE298

CSE300

GCS-1.39

Isis =>Horus => Ensemble Developed at Cornell University, Horus provides

such a flexible and extensive set of microprotocols that it may be configured so as to meet most GCS requirements.

Horus is able to do this by: transparently, by intercepting certain Unix

system calls through use of an intercept proxy OR

traditionally, through API toolkit.

GCS Overview - Horus

CSE298

CSE300

GCS-1.40


Each microprotocol in Horus can be represented as a block in a stack of Lego-style interconnecting pieces. These blocks have standardized interfaces

and may be placed in any sensible order where each block performs one of many possible communication features.

A process group can be optimized by dynamically including or excluding particular modules from its protocol stack.

TOTAL

FRAG

MBRSHIP

CRYPT

PARCLD

FC

STABLECOM

CSE298

CSE300

GCS-1.41


Application Programmer Interface

Application (group)

Unix Kernel

Shared Debugger

Horus Socket Library

Tcl/Tk

X- Library

Horus Intercept Proxy Horus Intercept Proxy

COM

NAK

FRAG

MBRSHIP

FC

TOTAL

COM

NAK

FRAG

MBRSHIP

MERG

COM

COM

NAK

FRAG

NAK

FRAG

MBRSHIP

PARCLD

TOTAL

n e t w o r k

CSE298

CSE300

GCS-1.42

GCS Overview - Horus Membership Service

Horus implements a partitionable membership service, with views that incorporate process identifiers and local counter values.

Three objects that form an integral part of its membership and messaging services: endpoints, groups and messages. Endpoint objects model the communicating

entity and may correspond to a machine, process, socket, etc.

Group objects maintain the local protocol state on an endpoint. They contain the group address and a view that lists endpoint addresses that represent other group members.

The message object is passed from layer to layer and provides for local storage.

CSE298

CSE300

GCS-1.43

GCS Overview - Horus Membership Service

The MBRSHIP microprotocol “runs a consensus protocol to provide its users with a virtually synchronous execution model” [11].

Horus provides a Horus Common Protocol Interface (HCPI). One interface of HCPI deals with membership services. “In the down direction, it lets an application

or layer control the group membership used by layers below it.

As upcalls, these report membership changes, communication problems, and other related events to the application” [11].

MBRSHIP

CSE298

CSE300

GCS-1.44

GCS Overview - GCS Overview - HorusHorus Multicast Multicast ServiceService

The other HCPI interface concerns the sending, receiving and stability of messages.

The COM microprotocol in Horus provides the group interface to low-level protocols such as IP, UDP and some ATM interfaces. This typically represents the bottom-most

block in the stack where its thread sits and waits for messages arriving via the NIC.

Horus, as a partitionable multicast service, offers the MERGE microprotocol to facilitate the location and merging of multiple group instances.

The NAK layer for negative-acknowledgement-based message retransmission.

COM

MERGE

NAK

CSE298

CSE300

GCS-1.45

GCS Overview - GCS Overview - HorusHorus Message Ordering Message Ordering ServiceService

The TOTAL microprotocol can be layered into the stack to provide totally ordered message delivery. Horus uses a token, rotated among the current

set of senders, to implement the TOTAL protocol. The MERGE microprotocol employs the virtual

synchrony principle to rank the processes it finds, employing the lowest-ranked process to maintain a master clock. Using this and the TOTAL microprotocol, the

logical timestamp of objects can be consistently performed.

Messages are numbered and use event count synchronization variables to reconstruct order if needed.

MERGE

TOTAL

FC

CSE298

CSE300

GCS-1.46

GCS Overview - SummaryGCS Overview - Summary

Group Communication requires three services:Group Communication requires three services: Membership Service Multicast Service Message Ordering Service

GCS-Applications have specific needs:GCS-Applications have specific needs: Fault Tolerance QoS Security Partitionability, etc...

Spillover of OO technologies found in GCS Spillover of OO technologies found in GCS development...development...

CSE298

CSE300

GCS-1.47

Emergence of JavaEmergence of Java

Previous work in GCS field was done mainly in CPrevious work in GCS field was done mainly in C

C++ added in object oriented advantages, but was C++ added in object oriented advantages, but was still too platform dependentstill too platform dependent

Communication protocols are handled via the GCS Communication protocols are handled via the GCS instead of the OSinstead of the OS

Java emerges as a new language and moves to a Java emerges as a new language and moves to a position where it could revolutionize the GCS fieldposition where it could revolutionize the GCS field

CSE298

CSE300

GCS-1.48

Advantages of JavaAdvantages of Java

Object Persistence (Serialization)Object Persistence (Serialization) Allows objects current state to be saved for later

retrieval. can be saved to disk or sent across network save format is independent of system platform

On deserialization a security check is run on the object. If security check fails an exception is thrown

Platform IndependencePlatform Independence No low level system calls needed to handle

network communication.

Low CostLow Cost.

CSE298

CSE300

GCS-1.49


SecureSecure

The current machines files are searched first before making calls to other JVMs.

Object oriented design and private data maintain security limits on user functionality.

Bytecode verifier ensures program only does what you allow it to do.

CSE298

CSE300

GCS-1.50


Remove Method Invocation (RMI)Remove Method Invocation (RMI) Most advantageous aspect for GCS. Allows method calls across local network or

across world. Java completely handles protocol. Any type of object and object behavior can be

sent across network. Sun constantly adding in new features.

Dynamic Class Loading Object Activation

CSE298

CSE300

GCS-1.51


Java Native Interface (JNI)Java Native Interface (JNI)

Enables Java to make method calls on non Java systems

Acts as glue between Java and native applications

Beneficial for GCS as it allows creation of clients for existing legacy applications

CSE298

CSE300

GCS-1.52


Java Naming and Directory Interface (JNDI)Java Naming and Directory Interface (JNDI)

Tracks various objects across the network Computer addresses File locations Users Printers Object groups

Enables quick and easy access to system resources for users in a GCS system.

CSE298

CSE300

GCS-1.53


Common Object Request Broker Architecture Common Object Request Broker Architecture (CORBA)(CORBA) Java can interface with CORBA via IDL or JNI Sun and IBM currently working on IIOP

protocol for RMI

Enterprise Java BeansEnterprise Java Beans Extends use of Beans to server programming. As it is Write Once Run Anywhere technology

the beans can easily be mapped to varying systems.

CSE298

CSE300

GCS-1.54

FilterfreshFilterfresh

Currently being developed at New York Currently being developed at New York UniversityUniversity

100% pure Java100% pure Java

Based heavily upon Java RMIBased heavily upon Java RMI

Handles all network trafficHandles all network traffic

Updates continue as Sun improves Java languageUpdates continue as Sun improves Java language

CSE298

CSE300

GCS-1.55

Filterfresh - Membership ServiceFilterfresh - Membership Service

Uses GroupManager class to maintain group Uses GroupManager class to maintain group information.information. Current members of group and the unique id’s View incarnation number Identity of group leader

Groups form by one member creating group and Groups form by one member creating group and others joining, the creator is the initial group leader.others joining, the creator is the initial group leader.

When new member joins group one of the current When new member joins group one of the current member sends its state to the new member via member sends its state to the new member via object serialization. This ensures a consistent view object serialization. This ensures a consistent view among all members.among all members.

Members can at any time request the current group Members can at any time request the current group view if they suspect a network failure.view if they suspect a network failure.

CSE298

CSE300

GCS-1.56

Filterfresh - Multicast ServiceFilterfresh - Multicast Service

All inter-group messages are sent through the All inter-group messages are sent through the leader.leader.

If leader crashes, group will elect a new leader.If leader crashes, group will elect a new leader. Leader determines if received messages are from Leader determines if received messages are from

correct view and will broadcast valid messages to correct view and will broadcast valid messages to group members.group members.

All new messages are blocked by leader until it All new messages are blocked by leader until it verifies that the current broadcast message was verifies that the current broadcast message was fully received. fully received.

System is considered ACK based as all messages System is considered ACK based as all messages require explicit acknowledgementrequire explicit acknowledgement

CSE298

CSE300

GCS-1.57

Filterfresh - Message Ordering ServiceFilterfresh - Message Ordering Service

Messages are processed in FIFO order.Messages are processed in FIFO order. All message are sent with current view number All message are sent with current view number

and a positive integer to determine correct order.and a positive integer to determine correct order. Message blocking and sequence numbers Message blocking and sequence numbers

guarantee synchronous views across group.guarantee synchronous views across group. Message sending will continue to send message Message sending will continue to send message

until a valid state is reached.until a valid state is reached. Leader sends appropriate response to sender

regarding acceptance of message Timeout occurs, message sender will request

an updated group view to recover from potential failures

CSE298

CSE300

GCS-1.58

Filterfresh Example - FT RegistryFilterfresh Example - FT Registry

System developed to demonstrate the abilities of System developed to demonstrate the abilities of Filterfresh.Filterfresh.

FT Registry is a fault tolerant RMI registry server.FT Registry is a fault tolerant RMI registry server. Arose from various problems in dealing with RMI Arose from various problems in dealing with RMI

registries.registries. Network failures prevent all calls Multiple servers all contain different information Servers that are resurrected on different

machines are unable to process old calls Creates groups of servers to maintain system in Creates groups of servers to maintain system in

instances of crashes.instances of crashes. Handles all network traffic in order to keep client Handles all network traffic in order to keep client

unaware of any system failures.unaware of any system failures.

CSE298

CSE300

GCS-1.59


Fault tolerance in FT registry.Fault tolerance in FT registry. Client attempts call to object on server Client connects to FT registry to get object

reference FT registry connects client to local server

CSE298

CSE300

GCS-1.60


If server is down: Since all information goes through the FT registry

it prevents the “server down” error from reaching the client.

Ouch!

CSE298

CSE300

GCS-1.61


FT registry uses stale copy of the downed server to get object information

Connects client to a different server that has duplicate object

Client is unaware of process and makes call on new server without knowing it’s a different server.

Reverse lookup

CSE298

CSE300

GCS-1.62

Filerfresh SummaryFilerfresh Summary

Still in early stages of developmentStill in early stages of development

Main drawback is it heavily depends on the Main drawback is it heavily depends on the network remaining mainly stable. Groups are network remaining mainly stable. Groups are unable to split and form smaller views.unable to split and form smaller views.

Future plans:Future plans: FTMulticastRemoveObject class Support for nested invocations

CSE298

CSE300

GCS-1.63

JgroupJgroup

Currently being developed at University of Currently being developed at University of BolognaBologna

100% pure Java100% pure Java

Based heavily upon Java RMIBased heavily upon Java RMI

Handles all network trafficHandles all network traffic

Partitionable GCSPartitionable GCS

CSE298

CSE300

GCS-1.64

Jgroup - Membership ServiceJgroup - Membership Service

Groups are created by two members collaborating Groups are created by two members collaborating on a view.on a view.

Uses reliable unicast invocation semantics.Uses reliable unicast invocation semantics. this guarantees that a method invocation

performed by a client will get a response from at least one of the servers

If group splits, new views are created by If group splits, new views are created by collaboration of split members.collaboration of split members.

Groups are able to merge back together.Groups are able to merge back together. state reconciliation protocol is executed to

collaborate on combined views Keeps invocation method transparent to client.Keeps invocation method transparent to client.

CSE298

CSE300

GCS-1.65

Jgroup - Multicast ServiceJgroup - Multicast Service

Still in early stages of developmentStill in early stages of development

Finds possible paths to destination instead of Finds possible paths to destination instead of always just direct routealways just direct route

Can get from A to B, and B to C, but not A to C

CSE298

CSE300

GCS-1.66

Jgroup - Message Ordering ServiceJgroup - Message Ordering Service

Messages from same sender are FIFOMessages from same sender are FIFO

Messages from different senders are not Messages from different senders are not guaranteed to be FIFOguaranteed to be FIFO

View number is included in sent messagesView number is included in sent messages

CSE298

CSE300

GCS-1.67

Jgroup SummaryJgroup Summary

Still too early in development to be effectively Still too early in development to be effectively usedused

Future plans:Future plans: Completion of the multicast system Possible improvement of low-level

communication protocols through IP multicast More work on view stage merging

CSE298

CSE300

GCS-1.68

Filterfresh vs JgroupFilterfresh vs Jgroup

Both are very similar, mainly due to basis on RMIBoth are very similar, mainly due to basis on RMI Filterfresh clogs server when an invoke fails, as Filterfresh clogs server when an invoke fails, as

each failure requires another registry lookupeach failure requires another registry lookup Filterfresh also causes a large system load on a Filterfresh also causes a large system load on a

bind, as data must be replicated to all servers. bind, as data must be replicated to all servers. Jgroup allows user to specify where data is Jgroup allows user to specify where data is replicated to.replicated to.

Main difference is that Jgroup is a partitionable Main difference is that Jgroup is a partitionable GCS while Filterfresh is based on the primary-GCS while Filterfresh is based on the primary-partition system.partition system.

CSE298

CSE300

GCS-1.69

The Java Shared Data Toolkit andThe Java Shared Data Toolkit andGroup CommunicationGroup Communication

Introduction to the JSDTIntroduction to the JSDT

JSDT and GCS requirementsJSDT and GCS requirements

JSDT in comparison to other GCS toolsJSDT in comparison to other GCS tools

JSDT and securityJSDT and security

Concluding remarksConcluding remarks

CSE298

CSE300

GCS-1.70

JSDT IntroductionJSDT Introduction

JSDT = Java Shared Data ToolkitJSDT = Java Shared Data Toolkit ““a toolkit designed to support highly interactive, a toolkit designed to support highly interactive,

collaborative applications written in Java” [2].collaborative applications written in Java” [2]. Developed at Sun MicrosystemsDeveloped at Sun Microsystems

Java API originally named “JavaShare” developed for applications in a shared data

environment commercial (free evaluation version available)

A modern, high-level GCS toolA modern, high-level GCS tool knowledge of the underlying network or

hardware architecture is NOT required primarily an application-level GCS tool

CSE298

CSE300

GCS-1.71

JSDT and GCS requirementsJSDT and GCS requirements

JSDT is marketed as a JSDT is marketed as a “collaborative” toolkit.“collaborative” toolkit.

Supports many of the Supports many of the GCS requirementsGCS requirements

The JSDT supports "full-The JSDT supports "full-duplex multipoint duplex multipoint communication among an communication among an arbitrary number of arbitrary number of connected application connected application entities -- all over a entities -- all over a variety of different types variety of different types of networks" [2].of networks" [2].

Duke.JSDT.gif courtesy Sun Microsystems, Inc. Copyright © 1996-98

CSE298

CSE300

GCS-1.72

JSDT and GCS requirements JSDT and GCS requirements (cont’d)(cont’d)

Written in JavaWritten in Java platform independence serialization

objects data messages

Event model useful for maintaining shared data useful in messaging

Exception handling improves fault-tolerance abilities

Java.logo.gif courtesy Sun Microsystems, Inc. Copyright © 1996-98

CSE298

CSE300

GCS-1.73


Client

Session

Registry

Channel

Data

ByteArray

Token

Managers

JSDT’s primary GCS tools:JSDT’s primary GCS tools:

CSE298

CSE300

GCS-1.74


ClientClient single communicating node uses point-to-point or multipoint

communications can be a member of any number of groups authentication occurs at the Client level

SessionSession abstraction of a group consists of a set of related nodes (Clients) maintains the state of the group and their

communications paths used to create ByteArrays, Channels, and

Tokens

CSE298

CSE300

GCS-1.75


RegistryRegistry maintains Session data, keeping it available to

Client applications maintains a transient database that maps names

to JSDT Client and Session objects

ChannelChannel defines the communication path between

Clients participating in a Session potentially multi-party determines the reliability of communications

path determines the orderedness of messages over it

CSE298

CSE300

GCS-1.76


DataData information sent between Clients over a

Channel can contain any completely serializable Java

object

ByteArrayByteArray information that is permanently, globally

available to all Clients within a particular Session

updated globally upon modification Client gets a reference to a ByteArray

CSE298

CSE300

GCS-1.77


TokenToken allows for the synchronization of shared data can provide for exclusive access to a particular

shared object

ManagersManagers types:

SessionManager, ChannelManager, ByteArrayManager, and TokenManager

provide security associate a “management policy” with a

particular shared resource authentication of Client requests

CSE298

CSE300

GCS-1.78


JSDT Membership ServiceJSDT Membership Service A Session defines a group of Clients.

Session defines subsets of Clients at the level of the shared data: ByteArray, Channel, and Token

A Channel interconnects Clients within a Session. Channel allows each Client to know what other

Clients are available for communication Channel provides a view-like service for Clients to

determine “who else is on”

CSE298

CSE300

GCS-1.79


JSDT Membership ServiceJSDT Membership Service JSDT was not designed for fault-tolerance JSDT does meet most of the “membership”

requirements of GCS partitionable

primary partition model– central server approach

– JSDT does not explicitly provide replication of data

Channel and Session can define a “partition” of communicating nodes (Clients)

CSE298

CSE300

GCS-1.80


JSDT Multicast ServiceJSDT Multicast Service JSDT Channel handles many of the GCS

multicast services Delivery integrity: JSDT won’t spontaneously deliver a

message

No duplication: JSDT won’t duplicate a message

Same view delivery: JSDT multicast communications are delivered at every node in the group of communicating nodes

Self-delivery: messages sent from JSDT Clients can be delivered to themselves

Termination of delivery: knowledge of the underlying structure of the JSDT is unknown.

(Strong) Virtual synchrony: fault tolerant requirement

Synchronous delivery: fault tolerant requirement

CSE298

CSE300

GCS-1.81


JSDT Message Ordering ServiceJSDT Message Ordering Service Channel provides the JSDT’s message ordering

services provides option for reliable or unreliable

communication provides option for data orderedness (FIFO

delivery)

fault-tolerant message ordering services are not explicitly provided in the JSDT causal and agreed delivery capabilities of the JSDT

are unknown implementation is possible

CSE298

CSE300

GCS-1.82

JSDT comparisonJSDT comparison

JSDTJSDT modern (1998) application level Java Virtual Machine

(Unix, PC, …) Written in Java

greater flexibility? collaboration

primary partition

Transis, Totem and HorusTransis, Totem and Horus older (~1996) transport level Unix

Written in C better performance?

fault-tolerance partitionable

JSDT vs. Transis, Totem and HorusJSDT vs. Transis, Totem and Horus

CSE298

CSE300

GCS-1.83

JSDT comparison (cont’d)JSDT comparison (cont’d)

JSDTJSDT

RMI, Sockets, LRMP, (HTTP - v1.5), ... extendable network

implementation designed for

collaboration

Filterfresh & JGroupFilterfresh & JGroup

UDP under an RMI mechanism (Filterfresh) improved

performance designed for fault

tolerance data / server

replication

JSDT vs. Filterfresh and JGroupJSDT vs. Filterfresh and JGroup

“modern” GCS tools 100% Pure Java

object serialization for object communication Attempt to keep underlying implementation

invisible to the user

CSE298

CSE300

GCS-1.84

JSDT and SecurityJSDT and Security

AuthenticationAuthentication provided by the Manager classes

Managers exist for ByteArrays, Channels, Sessions, and Tokens.– ByteArrayManager, ChannelManager, SessionManager,

TokenManager

A Manager authenticates Clients requesting to join a particular resource.

A Manager accepts or rejects a Client request, after verifying the Client’s response.

CSE298

CSE300

GCS-1.85

JSDT and Security (cont’d)JSDT and Security (cont’d)

Authentication exampleAuthentication example

Client join

Managed JSDTObject

Object Manager

The authentication process begins when a Client tries to join a managed object or when a Client tries to create or destroy a

ByteArray, Channel, or Token within a managed Session

CSE298

CSE300

GCS-1.86



Client

Managed JSDTObject

authentication request

challenge

Object Manager

The Manager then responds to the Client with an authentication request, containing a challenge object.

CSE298

CSE300

GCS-1.87



Client

Managed JSDTObject

response

Object Manager

The Client then replies to the authentication request with a response object.

CSE298

CSE300

GCS-1.88



Client

Managed JSDTObject

Object Manager

The Manager then validates the Client’s response, based on an agreed authentication policy.

CSE298

CSE300

GCS-1.89



Client

Managed JSDTObject

Object Manager

If the Client’s response is validated, the Client is authenticated and the request for service is granted.

authentication complete

CSE298

CSE300

GCS-1.90

JSDT IssuesJSDT Issues

Socket implementation Socket implementation Cannot handle Data messages greater than 8

Kbytes on unreliable (UDP) Channels. Data priorities are ignored.

LRMP implementation LRMP implementation No unreliable Channels. Data priorities are ignored.

RMI implementation RMI implementation No unreliable Channels. Data priorities are ignored.

HTTP implementationHTTP implementation version 1.5 only

CSE298

CSE300

GCS-1.91

Concluding remarksConcluding remarks

JSDT is ideal for creating a collaborative JSDT is ideal for creating a collaborative application or for adding collaborative capabilities application or for adding collaborative capabilities to an existing application.to an existing application.

JSDT is extendable, such that most of the GCS JSDT is extendable, such that most of the GCS requirements can be provided.requirements can be provided.

Fault-tolerance is not the primary goal of the JSDTFault-tolerance is not the primary goal of the JSDT A comparison to fault-tolerant GCS tools is

difficult. Creator of the JSDT, Rich Burridge, admits

that the JSDT could make use of more fault-tolerant services.

Future considerations include the use of JNDI and Jini to optionally handle the Registry responsibilities, improving fault-tolerance.

CSE298

CSE300

GCS-1.92

Collaborative CRCTool ProposalCollaborative CRCTool Proposal

IntroductionIntroduction Given the previous discussions, we want to

explore how a real collaborative application could be implemented with a GCS tool

We chose Java and the JSDT as our tool set The Collaborative CRCTool to be based upon

the CRCTool created in a previous semester However, new specifications developed

extending the initial design These specifications then mapped to a possible

JSDT implementation

CSE298

CSE300

GCS-1.93


CRC CardsCRC Cards OO Design Tool

We define a We define a crcProjectcrcProject that contains a vector of that contains a vector of crcCardscrcCards

crcProject

crcCard

crcCard

crcCard

crcCard

CRC Card SpecificInfo

Project Info

CSE298

CSE300

GCS-1.94


SpecificationsSpecifications Two main components

CRCServer CRCClient

CSE298

CSE300

GCS-1.95


CRCServer SpecificationsCRCServer Specifications The server should maintain a list of all allowed users, their passwords and

their access permissions – This file should be stored on local disk The server will be responsible for authenticating users attempting to

connect The server should allow for at least 10 people to work on a given

CRCProject at a time The server should allow for at least 10 CRCProjects to be worked on at a

time The server should only allow 1 person to edit a given set of CRCCard

data or CRCProject data at a given time – all other users attempting to edit should be forced in read-only mode

The server will be responsible for providing a filtered list of available projects to the client

The server will be responsible for providing the user with the means to create a new project and set its user access permissions

The server should have the capability to upload projects to a user The server should have the capability to download projects to local disk The server should provide a simple GUI for administration

CSE298

CSE300

GCS-1.96


CRCClientCRCClient Components

CRCProjectView CRCDataView CRCUserView CRCChatView CRCMainMenu

CSE298

CSE300

GCS-1.97


CRCClient SpecificationsCRCClient Specifications The client should provide the GUI interface for server select and client

authorization The client should be able to operate in both local and remote (server)

modes The client should be able to switch between modes during a single run The client should be able to upload or download projects from the server The client should provide the GUI interface to set user permission and

names on a new or uploaded project The client should provide a tree-like view of the open projects

(CRCProjectView) The client should provide for an edit/read-only view of CRCProject and

CRCCard data (CRCDataView) The client should provide for a read-only view of the users working on a

currently selected project (CRCUserView) The client should provide for a real-time text communications view for

user interaction (CRCChatView) The client should detect and notify the user upon loss of connection to the

server and or other users.

CSE298

CSE300

GCS-1.98


CRCClient Specifications (cont’d)CRCClient Specifications (cont’d) When opened in read-only mode, the client should display the user id of

the currently editing party to the user The user should be able to use the CRCProjectView to rename and cut

and paste CRCCards and CRCProjects The client should provide help to the user The client should be able to export a CRCProject to HTML

CSE298

CSE300

GCS-1.99


Brief overview of JSDT Sessions Clients The Registry Channels ByteArrays

Data Tokens

CSE298

CSE300

GCS-1.100


SessionManager

Client Client

Server

Client

Client

Client

Registry Registry

Registry

Session

ByteArray

Token

Token

ByteArray

Channel

socketsrmilrmp

Client computer Client computer

Server computerData

Client

CSE298

CSE300

GCS-1.101


Mapping the Collaborative CRCTool to the JSDTMapping the Collaborative CRCTool to the JSDT JSDT ComponentsJSDT Components

Clients crcClient crcServerClient

Sessions crcSession crcSessionManager

Channels crcControlChannel crcProjectChatChannel

CSE298

CSE300

GCS-1.102


Key

crcSessionManager

crcTool crcTool

crcServer

crcClient

crcServer-Client

Registry Registry

Registry

crcSessioncrcProjectAccess-

List

crcProject-Access-Token

TokenByteArray

crcContol-Channel

Java RMI

crcClientcomputer

crcClientcomputer

crcServercomputerData

LocalData

LocalData

Channel

crcProjectAccess

crcProject-Access-Token

crcClientGUI

crcClientGUI

crcClient

crcServerGUI

ThesessionManageris run as part ofthe crcServer

crcSM...

The crcSession iscreated by thecrcServer

The session isjoined by the clientsthrough thesessionManager

crcProject-Chat-

Channel

crcProjectUsers

crcProject1

crcProjectn

CSE298

CSE300

GCS-1.103


JSDT Components (cont’d)JSDT Components (cont’d) ByteArrays and Tokens

crcProjectUsers

Need to put project data into Session space Issue of granularity

– Levels

» Per Data Line

» Project

» Card

CSE298

CSE300

GCS-1.104


JSDT Components (cont’d)JSDT Components (cont’d) Per Data Line Granularity

Same Card can be edited at the same time Somewhat ridiculous

– Would be terribly confusing to the user

– Not really necessary

CSE298

CSE300

GCS-1.105


JSDT Components (cont’d)JSDT Components (cont’d) Project Granularity

One ByteArray and one Token per Project

Key

crcSessionManager

crcSession

crcProjectToken 1

TokenByteArray

Channel

crcProjectToken n

crcProject1

crcProjectn

CSE298

CSE300

GCS-1.106


JSDT Components (cont’d)JSDT Components (cont’d) Card Granularity- Model I

One ByteArray and Token per Card

Key

crcSessionManager

crcSession

crcProjectDataToke

n 1

TokenByteArray

Channel

crcCardDataToken n

crcProjectData 1

crcCardtData n

crcCardDataToken 1

crcProjectDataToke

n n

crcCardtData 1 crcProjectD

ata n

CSE298

CSE300

GCS-1.107


JSDT Components (cont’d)JSDT Components (cont’d) Card Granularity- Model II

One ByteArray and Token per Project

Key

crcSessionManager

crcSessioncrcProjectAccessList 1

crcProject-Access-Token 1

TokenByteArray

Channel

crcProjectAccessList n

crcProject-Access-Token n

crcProject1

crcProjectn

CSE298

CSE300

GCS-1.108


JSDT Components (cont’d)JSDT Components (cont’d) Card Granularity- Model II (cont’d)

To request an edit:– Grab the crcProjectAccessToken exclusively – If this

fails, keep trying– Read in the crcProjectAccessList– Check the list to see if the name of the crcCard that we

wish to edit is present– If it is already there, someone else has it open for editing

and we may not have write access. Give back the Token and return a failure (read-only)

– If it is not there, we write the name of the card into the vector, write the modified crcProjectAccessList back to the Session ByteArray, and release the crcProjectAccessToken

– The card is now ours for the editing - Return a success

CSE298

CSE300

GCS-1.109


JSDT Components (cont’d)JSDT Components (cont’d) Card Granularity- Model II (cont’d)

To write an edit:– Grab the crcProjectAccessToken exclusively – If this

fails, keep trying– Read in the crcProjectAccessList– Remove the crcCard name from the list– Write the crcProject (this will notify all listening Clients)– Release the crcProjectAccessToken

Additions– lock the crcProject specific data

Removals and Renames– lock the crcProject specific data and the crcCard

Clients must behave

CSE298

CSE300

GCS-1.110


ConclusionConclusion Model I vs. Model II

Large number of items vs. big items– Which is more efficient?

Model II better from design encapsulation point of view Performance must be tested with JSDT

JSDT provides adequate mechanisms for handling the requirements of the Collaborative CRCTool

However, certain things could be improved upon Allowing inheritance from Token, etc…

CSE298

CSE300

GCS-1.111


A Note on JSDT and Partitioning (Future Work)A Note on JSDT and Partitioning (Future Work) JSDT does not natively handle the partitioning

problem

Is it possible to provide this functionality at the application level? In general (as has been discussed), this is very hard Certain instances not so difficult

– The addition of new cards, etc… We might be able to handle these

– Requires real-time testing

Would require strict rules

In the end, a moderator would still be necessary in order to resolve conflicts

Interesting challenge

CSE298

CSE300

GCS-1.112

ConclusionsConclusions

Group Membership Services attempt to solve Group Membership Services attempt to solve extremely complex problemsextremely complex problems

Early GCSs provide foundation protocols upon Early GCSs provide foundation protocols upon which modern, high-level tools are builtwhich modern, high-level tools are built

Properties of Java enhance GCS applicationsProperties of Java enhance GCS applications

JSDT is ideal for creating a collaborative JSDT is ideal for creating a collaborative applications, such as Collaborative CRCToolapplications, such as Collaborative CRCTool

CSE298

CSE300

GCS-1.113

ReferencesReferences

Baratloo, P. Emerald Chung, Y. Huang, S. Rangarajan, and S. Yajnik. Filterfresh: Hot Replication of Hava RMI Server Objects. In Proceedings of the 4th Conference on Object-Oriented Technologies and Systems (COOTS),Santa Fe, New Mexico, April 1998.

R. Burridge. Java Shared Data Toolkit User Guide, Version 1.4. Sun Microsystems, Inc., Mountain View, California, June 1998.

R. Burridge. Java Shared Data Toolkit Implementation Guide, Version 1.4. Sun Microsystems, Inc., Mountain View, California, September 1998.

D. Dolev and D. Malki, "The Transis Approach To High Availability Cluster Communication", Communications of the ACM, Vol. 39, No. 4, April 1996.

Montresor. The Jgroup Reliable Distributed Object Model. Tobe published in Proceedings of the Second IFIP WG 6.1 International Working Conference on Distributed Applications and Interoperable Systems, Helsinki, June 1999. Technical Report UBLCS 98-12, December 1998.

L. E. Moser, P. M. Melliar-Smith, D. A. Agarwal, R. K. Budhia and C. A. Lingley-Papadopoulos, "Totem: A Fault-tolerant Multicast Group Communication System", Communications of the ACM, Vol. 39, No. 4, April 1996.

D. Powell, "Group Communication", Communications of the ACM, Vol. 39, No. 4, April 1996.

CSE298

CSE300

GCS-1.114

References References (cont’d)(cont’d)

M. Reiter, "Distributing Trust with the Rampart Toolkit", Communications of the ACM, Vol. 39, No. 4, April 1996.

R. van Renesse, K. Birman, R. Cooper, B. Glade, and P. Stephenson. The Horus System. In K.

Birman and R. van Renesse, editors, Reliable Distributed Computing with the Isis Toolkit, pages 133-147. IEEEComputer Society Press, 1993.

R. van Renesse, K. Birman and S. Maffeis, "Horus: A Flexible Group Communication System", Communications of the ACM, Vol. 39, No. 4, April 1996.

Schiper and M. Raynal, "From Group Communication to Transactions in Distributed Systems", Communications of the ACM, Vol. 39, No. 4, April 1996.

Vitenberg, Properties of Distributed Group Communication and Their Utilization; Institute of Computer Science, The Hebrew University of Jerusalem, Jerusalem, Israel, 28 January 1998.

T. Wada, T. Yoshida, Object Groups and Group Communication in a Distributed Object-Oriented Programming, Proceedings of the 9th International Workshop on Database and Expert Systems Applications, 1998, Institute of Electrical and Electronics Engineers, Inc.

CSE298

CSE300

GCS-1.115

References References (cont’d)(cont’d)

L. E. Moser, Y. Amir, P. M. Melliar-Smith, D. A. Agarwal, Extended Virtual Synchrony, Department of Electrical and Computer Engineering, University of California, Santa Barbara, CA.

Documents

CSE298 CSE300 GCS-1.1 Group Communication Joshua A. Boggis, Richard C. Gronback, Harry L. Sauers, Adam P. Uccello Computer Science & Engineering The University