Remotely Filtered Event Streams for Distributed Applications.

The Problem Domain

We have some innovative message passing software that supports remote filtering of messages in the form of "events". The idea behind this support is that many networked applications don't really need all the information they receive. For example, if you're playing multi-user Quake or Doom over the network, the game is continually broadcasting information about your position, orientation, weapon, etc. to all the other players. But if they can't see you because they are in another room, that information is useless. It wastes network bandwidth and CPU cycles to send and receive it.

One approach to suppressing this unnecessary data is to work inside the application, building complicated message exchange systems where both the event sender and the event receiver cooperate to try to suppress events. However, debugging such protocols is hard and requires a lot of application-specific knowledge. Creating protocols for one situation doesn't help you with another application, and you're back to square one if you get a new receiver with a different idea of what information is "unnecessary".

Our derived event channels offer a conceptually simple solution to this situation. Event senders don't have to do anything except blindly submit events. Event receivers can specify a function, F, that is to be used to remotely filter events. The event infrastructure takes care of moving F to the event source and running it to discard events. We use dynamic code generation to create a native-code version of F s o that we can work in heterogenous environments and so that event filtering is efficient. (You could do this heterogenous code motion with something like Java or TCL, but those interpreters are too slow to use in the event flow of something like Quake.)

The challenges and benefits of using this remote filtering capability are inherently application-specific. This project is to conceive and demonstrate the use of this facility in some new application. (Hopefully one in which you have some non-trivial familiarity.)

Here is what you need to do.

1. Briefly familiarize yourself with the ECho event system to know what kinds of remote filtering are possible.
   • A complete paper on the remote filtering is under preparation and is available from Greg Eisenhauer.
   • There is also information on the web page for the event system, ECho.
2. Propose a project. Be able to describe the dataflow of the application and how you can use remote filtering to reduce that dataflow. Extra points for coming up with situations where an "inside the application" approach wouldn't work well. For example, if the event sender can't know a priori how receivers might want to filter their events.
3. Create at least a prototype to demonstrate your application and approach. The scope of this depends upon your target application. If you are targeting improvements in some existing application whose implementation you can change, installing remote filtering is the best way to demonstrate your idea. On the other hand, if you have in mind a whole new Internet-based service that is only feasible because of remote filtering, you don't have to write the whole thing from scratch. A prototype that demonstrates your plan will do.
4. If time permits, do measurements to show performance improvement and/or significantly reduced resource utilization in the application.

Deliverables

• A report describing your application, your use of remote event filtering and the benefits that come from it.
• Source code for your application or prototype.

Evaluation
Based on novelty of the application and the quality of the report turned in.

updated by eisen, 8/31/99