JGroups - A Toolkit for Reliable Multicast Communication

Below is a selection of project suggestions related to JGroups. Each project can be done by a 1-4 person group. Please contact me if you are interested, or need more information.

Write a C implementation of an ethereal plugin which understands the JGroups wire format and displays information about the JGroups messages (e.g. sender, receiver, headers) in ethereal.
Contact Bela for more details on this project

Using JSRs 197 and 82, Bluetooth can be supported on JGroups. The idea is to write a new transport (extending TP) which uses Bluetooth to send and receive messages. Possibly, a new discovery protocol has to be written as well, extending Discovery, unless Bluetooth supports a 'multicast'-like (or cell broadcast) discovery mechanism.
This functionality could be simply used in JGroups-ME, so JGroups-ME and JGroups could actually talk to each other using Bluetooth. For example, a cell phone running JGroups-Me could talk to a computer running JGroups (J2SE).
Contact Bela for more details on this project

1. Implementation of Jini Discovery and Join protocols with JGroups
2. Adapter to JGroups Discovery and Join service, which makes it look like a pure Jini Discovery and Join service (Lookup Service)
3. Reliable Jini services: a service is created multiple times on different nodes. Clients get a proxy which knows about the multiple services. Proxy has a policy to choose a service. When a service fails, another service is chosen automatically by the proxy stub. Service group info is piggy backed on responses (if changed)

The discovery and join protocols of JGroups rather than Jini are used for communication between JGroups-based LookupServices (LUs). For communication between Jini based LUs and for client discovery and jon of LUs the Jini Discovery and Join adapter is used.

Provide an implementation that conforms to the JavaSpaces spec

Provide an interface which allows for the contents of replicated data structures (such as the ones above) to be saved persistently. Whenever a member comes up, if it is the first member, it will retrieve its initial state from the persistent storage through this interface. If it is not the first member, it will get its state from the oldest member (the coordinator). Whenever a replicated data structure is updated, each member writes that change to the persistent storage.
A simple implementation would use file-based storage, a more sophisticated implementation could use a database for storage. The implementation to be chosen should be configurable, e.g. through using a PersistenceManagerFactory.

Goal is to build a load balancer process which accepts incoming HTTP(S) requests, forwards them to one of the HTTP servers in a farm, and returns the response to the client. The HTTP servers form a group and the load balancer needs to know which servers are currently up and running, and needs to be notified of group membership changes.
The load balancer can have different policies on how to forward requests: e.g. always forward to the same server (sticky), round-robin (works only if HTTP session state is replicated), random etc. The HTTP server could even use the group channel to periodically send their load status, so requests can go to the least loaded server (this also requires session replication).
This project is largely about TCP/HTTP (probably requires JDK 1.4's NIO capabilities), but also makes use of JGroups for the HTTP server group.

ReplicatedTree can be used to model a filesystem: a node is either a directory or a file. Attributes can be for example (1) the creation time, (2) size and (3) contents (as a byte buffer). A ReplicatedTree can be populated given an initial directory (see in ReplicatedTreeDemo). Subclasses of FileReader/FileWriter would have to be provided, which use ReplicatedTree instead of the filesystem. Any FileReader will access the 'contents' attribute of a file in the ReplicatedTree. The FileWriter would change the attribute accordingly. Any FileReader should listen for nodeChanged() notifications and determine whether it is affected. If it is, it will need to re-read the underlying contents and re-display them. This can be compared to 2 authors using emacs on the same file on a distributed filesystem: when both of them make changes, when anyone saves its changes, the other will see them (oevrwriting its own changes). A further sophistication could add file locking/unlocking to the model.

A lightweight protocol which is located towards the bottom of the stack and is usually dormant (no resource usage, almost no overhead). It accepts a small set of events for adding and removing protocols from the running protocol stack, and interacts with the latter in order to do so. Currently, we assume that the new protocol class is already located at the receiver's end, however, in the future the protocol may be given a URL from which to load the class for the protocol to be inserted.
The benefits are e.g. to add a tracing protocol to an already running stack to inspect some faulty runtime behavior, without having to shutdown and restart the stack.
The client to send such an event to a running stack can be similar to org.jgroups.tests.Ping.

Protocol which contains a Java interpreter (e.g. beanshell). Such a protocol can be dynamically inserted into a running protocol stack (see above) for debugging purposes. A client (text or GUI-based) would have to be written: it would send commands to be interpreted to the interpreter protocol and receive response events (e.g. output from the interpreter). The client and interpreter protocol could communicate via a separate channel (e.g. a TCP socket), or they could use a program similar to org.jgroups.tests.Ping.

Instead of specifying a protocol stack string, which is very strict with respect to consistency and order of the protocols, the user just defines what properties he would like to have in the stack. For example, a user might specify that he wants fragmentation and total order, but doesn't need to know that FRAG needs to be 'below' TOTAL as in the protocol stack specification. The property-based specification internally generates a regular protocol specification and uses it to create a protocol stack.

A GUI which guides the user through the process of creating a protocol stack specification. The constraints between protocols are (a) defined in a protocol itself (e.g. RequiresServices() and ProvidedServices()), or defined externally. They are read by the wizard and a decision tree is created. The final result is a string specifying the stack properties, which is valid.

Based on static or dynamic 'sliding window's for receivers and senders. Receiver sends message to receiver when window is full and sends another message when window was emptied below a certain threshold. Project involves studying literature on flow-control (e.g. TCP).

Keeps track of primary views in the event of partitions. Only members in primary views can make progress (i.e., modify their state etc.) When views of the same group merge, the state of the pimary view is accepted by all non-primary members. "Building Reliable Interoperable Distributed Objects with the Maestro Tools" [Vaysburd, 1998] describes one possible approach to implement primary partitions.

Debugging/trace protocol wrapped around the layer(s) to be inspected. This could be 1 single layer, or an entire stack. GUI displays messages traveling up/down the stack. 'Step mode' enables single stepping through protocol stack. Filters define what types of events/messages are displayed. Possibility to set breakpoint, based on logical assertion. Possibility to reorder events, delete events, or inject new events into the stack.

• Possibility to plug in 'test code' that verifies that a prot. layer is correct.
• Clearly defined interface between GUI and debugging layer.
• Goal: to visualize message sending/reception/delivery in a prot. stack.

The TUNNEL layer allows traffic to pass through firewalls. A JRouter process is started outside the firewall. Every channel has a TUNNEL layer as bottommost layer, replacing the UDP layer. It is configured with the TCP address of the JRouter (parameters of TUNNEL). When started, TUNNEL established a TCP connection to JRouter, over which it sends all outgoing traffic. Incoming traffic is also send via this connection by JRouter.
The problem with such a solution is that JRouter is a centralized single point of failure. This project would modifyJRouter as follows: the connection between a channel behind the firewall and JRouter outside the firewall is via TCP, but JRouter uses IP multicast to re-cast outgoing traffic to its destination channels. When incoming IP multicasts are received, they are sent via TCP to the channel. Thus, every firewall would use 1 JRouter for tunneling, and then re-multicasting the outgoing traffic.

Design and implementation of an example network. Simulate partitioning of the network and its consequences on JGroups' GMS layer.

Study architecture / implementation of RMI. Use SUN's source code or Ninja (Berkeley).

• Look at active and passive replication.
• Show alternatives (document). Look at intrusive and non-intrusive designs (transparency). Design solution and implement it.
• Demo based on modified RMI

This is essentially about making JGroups (designed for LAN environments) run well over the Internet (WANs). Build a hierarchy of groups, each with different properties, linked by members who are present in more than one group. For example link a group behind a firewall to an outside (WAN-based) group and exchange both state and messages between groups. 'Mount' a local group tree (e.g. ReplicatedTree) into a global tree and have the changes to the local tree propagate to all other local trees connected to the global tree. The keyword here is scalability, we want to be able to for example stream video/audio to thousands of clients spread over multiple groups.
Contact Bela for more details on this project