NCSAHabanero

[ Previous ] [ Index ] [ Next ]

-------------------------------------------------------------------
How to control which events have permissions to execute
-------------------------------------------------------------------

Arbitrator

Background Information

In most collaborative systems, when a local application generates an event and sends it off, the other collaborators will usually receive the event. In Habanero, you you normally want all events to propogate. However, sometimes you may not want some instances of a hablet to receive the event. Sometimes only one client should be able to do something as a result of the event. At other times, you may want to process the events before sending them on.

In Habanero, we have an object called the arbitrator to make such decisions. If you look at the examples section below, you can see some of the different ways to use arbitrators.

How does this work?

Central Arbitrator

The central arbitrator is basically the generic arbitrator. Because it is the arbitrator you will most often use, it is the default arbitrator. It passes every event it receives.

Limit Arbitrator

The limit arbitrator provides locking. Locking allows a participant to prevent other instances from sending specified events. For example, in a drawing program, if one user grabs a box and starts moving it, that hablet can set a lock on that box, so that other participants cannot also grab that object at that time.

Read the Limit Arbitrator pattern if you want to learn how to use this.

Examples

Here are some other uses for arbitrators.
Game Rules
People usually take turns when playing a board game, and there are usually a limited number of legal moves. An arbitrator can decide whose turn it is, whether a move is legal or not, and whether to allow or disallow the propgation of the event generated by a player's move. Checkers [Outside link] is an example of this.

 
Gateway to an outside server
Such an arbitrator acts as a proxy to an outside service so that the outside service sees all the hablets as one client.

For example, if you have a joint web session, instead of each instead of each participant connecting separately to the web server, only the arbitrator connects to the server. The server will only see one client, the arbitrator.

Another similar situation is a joint telnet session. The arbitrator makes the telnet connection to the remote host, and so that host only sees one user attaching. The arbitrator takes care of forwarding all the characters in the telnet session to and from the participants.
 

Main server in a client-server relationship
An arbitrator could even be a full-fledged server in the client-server model. We have a simple example of this in our voting tool. [Outside link] A special client starts this tool and lets the user choose the voting criteria. The initial instance of the voting tool sends this startup information to the voting tool arbitrator, which sends out ballots to all participants based on that start-up information. Then each participant fills out the ballot, and the arbitrator collects that information. Finally, the arbitrator reports the results to all the participants.

Most hablets are based on replication. Each particpating hablet knows the state of things. Habanero sends events to each instance of the hablet and each instance updates itself. However, Habanero also supports a classic client-server model as well as anything in between.
 

Simulation Ticks
The Wind Tunnel's [Outside link] arbitrator sends out clock tick events to keep the simulation on each participant in lock-step with each other. It then waits for an acknowledgement from each participant before sending out the next tick to allow the participants on slower machines to stay synchornized.

What next?

Learn how to create your own arbitrators. [Not yet written]

Habanero® is a registered trademark owned by The Board of Trustees of the University of Illinois. Copyright 1996-1998. All rights reserved.   Java(TM) is a proprietary trademark owned by Sun Microsystems, Inc.
NCSA
The National Center for Supercomputing Applications
University of Illinois at Urbana-Champaign

Contacts page