FTS Projects

1. FTS Porting and Cross-Operation
   Description: FTS was designed from the ground up to be portable, in the sense that its only platform dependency is CORBA. Also, FTS allows mixing clients and servers from different platforms, as long as these platforms can interface with each other. In most cases, this boils down to having the group communication component operate on all the server platforms, which is quite common. However, portability has yet to be proven. In this project, the students are required to port FTS code to alternate platforms and reach a state of mixed-platform operation. This type of project gives the students a large choice of platforms and environments to choose from. You can port FTS, for example, to C++ running on Windows XP using MICO as an ORB and Ensemble. Alternatively, you can also use Spread as a GC component.
   Team size: 1-4 students, depending on how far your porting goes. A cross-language port would require at least 3 students. On the other hand, porting FTS/Java to use an alternate GC or an alternate ORB is for at most 2 students.
   Development environment: Depending on your choice of target platform.
   Prequisits: Distributed Systems (recommended). The participants are guaranteed to learn lots of new interesting stuff..
   Required fields of knwledge: Java (mandatory), CORBA and your target porting platform (optional).



2. Negotiating Multiple LMRs
   Description: An FTS partition is considered primary after it has acquired lease keys from a quorum of LMR servers. These servers are already implemented, and so is a basic quorum client that works on a single LMR. The problem of negotiating multiple LMRs remains an open challenge:
   • Technically - implementing a "quorum client" engine that can accept various policies for accessing LMRs, such as: closest LMRs first, a predefined order of LMRs, "use what you have first" (first access LMRs to which you have keys from the previous partitions), etc.
   • Theoretically/empyrically - exploring various algorithms such as above for acquiring quorum leases. Which algorithms ensure that a quorum lease is finally achieved? How fast can this be done? Can starvation be avoided when multiple partitions exist long enough? Is the current LMR model of operation sufficient enough for guaranteeing various properties of the negotiation algorithm (safety/liveness/fairness)? etc.
   Team size: 1 student, graduate only. This project involves a fair amount of research and is very likely to evolve further..
   Development environment: Linux + Java + ORBAcus-4.X, any IDE of your choice.
   Prequisits: Distributed Systems, CDP, Distributed Algorithms. These prequisitss can be flexed for proper candidates
   Required fields of knwledge: Java, CORBA.