Project Ideas

The descriptions are relatively sketchy and the details given are not hard requirements but meant to get you thinking about possibilities. Each project can be done by one or more students. If you have specific interests in the general systems area, we can probably create a project around these interests.

Impact of Scheduling on QOS

There are two important interactive performance metrics we wish to optimize in a collaborative system: feedback – the response users gets to their input, and feedthrough – the response users get to others’ input. It is useful to separate the processing of these in different threads. In fact, it is possible to create a separate thread for each remote user. Even more fine-grained, there may be a pipe-line of producer-consumer thread processing the feedthrough of a specific user to, for instance, add timestamps or compress it. It is possible that one may have to tradeoff fast feedback for fast feedthrough. This may happen if all of these threads execute on the same computer, the computer is of small processing power (say a mobile computer) and either the feedback processing is high or the feedthrough processing is high (which may happen when a large number of remote users have to be sent feedthrough).

Intelligent scheduling may allow us to make the tradeoff between feedback and feedthrough times in a deterministic manner. In fact, real-time or proportionate scheduling may help here. To illustrate, consider a checkers program running on mobile computers. There may be two users collaboratively playing against the computer while another user simply watches. We want the user who makes a move to get feedback quickly to his move. In addition, we want the other active user to not get feedthrough much later as otherwise the collaborators would waste time and energy checking if each of them is seeing the same display. Similarly, we have found the scheduling policy makes a perceptible difference to the performance seen by the local and remote users when dragging an object. Mechanisms that give communication higher priority slow the local user down, while the reverse increases the latency seen by the remote user. We can make the priority user settable to let the user make this tradeoff, but the ideal would be to implement a policy for automatically ensuring that the local threads get no more of processing time than is required to make sure the local user sees no perceptible lack of response, and giving the rest of the processing time to remote users to reduce the latency seen by them. Intelligent scheduling may also be necessary to get reliable experimental data regarding feedback and feedthrough.

This project will investigate the impact of scheduling on keeping feedback and feedthrough times within the desired bounds. If this cannot be achieved, one may want to give priority to feedback and log and mine date to give users an idea of the difference between feedback and feedthrough times.

Performance of different shared layers

It is possible to share different layers of an application: framebuffer, window, toolkit or data. It is generally believed that sharing a higher-level layer improves performance. However, the extent of this gain has not been determined for various combinations of layers. Moreover, it is not clear there is always a gain. Compression of lower level events may be as good as sending higher-level events, as long as the compression is efficient in terms of space and time. Furthermore, higher-level layers maintain more state, which needs to be dynamically created/destroyed when a user joins/leaves Thus join/leave times may be slower with higher level sharing but feedthrough times smaller.

This project will compare the performance benefits/drawbacks of sharing different layers.

Replication vs. Centralization

We have done some preliminary studies comparing the performance of centralized and replicated architectures. These show the benefits of making dynamic transitions between the two architectures when the application is compute-intensive. There are two possible extensions to this work. First, explore the benefit of dynamic transitions as a small interactive replicated conference transitions to a large centralized presentation. Second, to implement dynamic policies for making these transitions based on observed delays.

Energy-Aware Collaboration

The amount of energy dissipated in a mobile computer is a function of the amount of information it communicates and how frequently it communicates. Some collaborative applications can offer multiple degrees of coupling. For instance, when an object is dragged, one could communicate all incremental positions of the mouse or only the end position. Similarly, one can transmit characters as they are typed or when the RETURN key is used to complete the message. When a user is interacting with multiple collaborative applications (say a chat and a whiteboard), it may be possible to batch the input or output to reduce the number of times the communication device is powered on. The amount of communication may also depend on the level of the shared layer. Finally, it may be a function of the architecture – a replicated architecture requires communication to each of the peers whereas a centralized architecture requires communication only to a central computer.

This project will investigate how the collaboration semantics and implementation can be adapted to conserve energy.

Fault tolerant architecture

For long-lived collaborations, such as the qual scheduling example, it is important that the conference state to always be available. This project will use incorporate state of the art fault tolerant techniques to a general purpose collaboration environment. This is an ideal project for someone taking this course together with comp 243 – the distributed systems course.

Sharing Open Office Tools

We see two trends in collaboration environments. Usually a general-purpose centralized window sharing system is used to share a collaborative application. When people get really serious about the application, a custom implementation is created to share it. For instance collaborative environments initially came with the application sharing system and special chat and whiteboard applications. As people realized the usefulness of sharing power point, they build custom presentation tools (in LiveMeeting and Webex, for example). The natural progression of this idea is to build special-purpose Word, Excel and other office programs. Unfortunately, interacting with MSFT programs is hard because they are too complex and not open enough. The Java-based open Office tools may not have this problem. Therefore it would be useful to try and create custom implementations for these tools using the various design principles we learn in class.

Context-Specific Presence

Instead of sharing an Office tool, it may suffice to give information about what you are doing with the tool. For example, how long has it been since you last interacted with it, what file is being manipulated by the tool, and what changes have you made recently to the file. This kind of information is an intermediate between full sharing and the kind of presence information provided by IM systems. One can think of it as context-specific presence as it gives others presence information in the context of some tool. It would be useful to implement this idea for Office tools.

Collaborative Qual Scheduling

There are several parties involved in scheduling quals. Students must submit their choices. Professors must enter their expertise and scheduling conflicts. Next the quals must be scheduled. So far, they have been scheduled completely by a qual committee. From next year, the qual committee will only schedule the three examiners of each exam. The examiners will then figure out the exam time and room. This project will develop an application that allows all of these parties to collaborate with each other to schedule the exam.

Adaptive Biological nanoManipulator

The nanoManipulator project allows scientists to collaboratively explore material at the nanoScale, but it is a specific C++ implementation. A new biology-oriented magnetic nanomanipulator system is currently being implemented in  Java. Change its implementation incorporating the design and architectural principles you study. In particular, allow it to dynamically add remote collaborating users, and perhaps to transition between centralized and replicated architectures in response to changes to the number of users interacting with the system.

The nanoManipulator project allows scientists to collaboratively explore material at the nanoScale. Its current version is being re-implemented in Java. Change its implementation incorporating the design and architectural principles you study. In particular, allow it to dynamically transition between centralized and replicated architectures in response to changes to the number of users interacting with the system.

Operation Transformations

Operation transformations allow replicated objects to be kept consistent without requiring write operations to block. They have been developed for specific applications including text editors, spreadsheets, and structured documents. Moreover, they do not allow inconsistent operations to be merged in a flexible fashion. Add flexible operation transformation to a general purpose environment supporting consistency between replicas of arbitrary Java objects.

Concurrency Control

There are many dimensions to concurrency control including granularity of locking, implicit vs. explicit locking, and mediated vs. unmediated locking. Provide a single framework to support the various locking policies that have been supported.

Undo

Add state of the art undo techniques to a general-purpose collaboration environment based on operation transformation techniques above.

Groupware widgets

Some widgets such multi-user scrollbars and telepointer traces have been created specially for group collaboration. Identify and implement them in a general framework.