CS 457, Fall 2004

Computer Networks

A Systems Approach

If you are looking for project partners please e-mail the instructor.

Project Due Dates:

Thursday, Sept 30th: Project title, half page abstract, and group member names (3-5) are due by e-mail. Please send e-mail in pure text form and write "CS457 Project" in subject line.
Thursday, Oct 7th: You will receive an e-mail from me by this time to ok your project. The e-mail may contain some suggestions. I may also ask you to schedule a meeting with me to discuss your project.
Thursday, Oct 21st: Project Architecture Document. Due in class. The document should be at most 4 pages long and should clearly describe (i) the goal of the project, (ii) the architecture of your service/protocol/tools/middleware illustrated with supporting figures and diagrams, (iii) the current state of implementation, and (iv) a list of the remaining milestones to project completion.
Thursday, Nov 18th: The Implementation Report. Due in class. This is the architecture document you sent before, now fleshed out with implementation details.
Thursday, Dec 9th: Final Report. Due in class. This is the implementation report you sent before, now fleshed out with data on experimental evaluation. Hence, it includes, the final design, implementation, and experimental evaluation results of the project.

Project Ideas:

The class will involve a group project that accounts for 15% of the grade. Projects should be done in groups of 3-5 people. I would like to encourage everyone to think of network-related project ideas. If you can't think of your own project, on this page, I am offering suggestions for specific projects that you are weclome to work on.

Wireless Multicast: In this project you will augment 802.11 with a reliable multicast capability. The problem with reliable multicast is the need for acknowledgements. In a trivial scheme a sender multicasting to N receivers requires N acknowledgements. This may not be practical when N is really large causing an "implosion" at the sender. A clever scheme is needed to reduce the ACK implosion problem.
LAN Simulator: This simulator will allow packet-by-packet simulation of different MAC protocols, including Ethernet, FDDI, etc. The user should be allowed to change hardware parameters (e.g., link capacity) protocol parameters (e.g., THT), as well as traffic parameters (e.g., average packet interarrival time). The simulator should accurately compute various LAN statistics. Important statistics include average packet delay, link utilization, and aggregate offered load.
Monopoly Online: In this project you will implement the distributed protocol monopoly-online. The protocol allows a set of clients to connect to the "monopoly" server which implements the monopoly game. The protocol should allow a new client to browse who else is waiting to play. It should allow the client to invite other waiting parties to a game or join an existing group waiting for an additional partner or partners. Once the desired number of players is reached, the game begins. The server should be able to handle multiple concurrent games at the same time. The protocol makes sure that all players of a givern game see the current most updated state of the game board, as well as the ownership of all properties. The server implements the bank, and rolls the dice.
Distributed Auction System: Develop a networked application that allows a group of geographically distributed individuals to hold an Auction across the Internet (as on e-bay). The software will ensure that all bids are reliably delivered to everyone in the same order. You may view your software as an application-layer protocol that ensures ordered delivery, and an application front-end that interfaces with the user.
Multimedia Chat Room: Chat rooms are examples of client-server applications where a single server is responsible for sharing messages among a group of clients. In this project you will implement a multimedia chat line in which individual clients can "subscribe" to the text feed, audio feed, graphical whiteboard feed, and possibly video feed. Text, voice, graphics, and video will then be shared among all participating clients in a timely and consistent manner.
Home Web: It would be nice if future home appliances could be on the web. For example, by logging in to your home's web page, you would be able to browse your refrigirator from work (the fridge presumably knows its contents using a bar code scanner), and figure out if you need to pick up any groceries on the way. This project implements a home web network. In this network, each appliance has a small micro-processor mote and a web page that is maintained by the appliance itself. A user with a regular browser and the correct password should be able to interact with the appliance via the web. The main challenge is to implement web service on motes.
Smart Room: Choose your own smart room theme. What would you like buildings of the future to be able to do using a small wireless network of computing equipment and sensors? The handout on Sentient Computing gives some ideas. In this project you will be working with wireless Motes running TinyOS. Each mote is equipped with a small microprocessor, radio transmitter, and a light sensor. Motes will be able to communicate with each other and with a PC base station. The challenge lies in networking the motes, implementing suitable communication protocols in the new wireless environment, and writing your distributed application software which is the highlight of the project. A good project will also implement an innovative user interface for interacting with the application.

If you would like your application to turn on and off any switches, lights, appliances, or other electical equipment in the room, you may also interface the workstation with the ActiveHome kit available with the instructor. The kit includes electrical hardware that allows a PC to switch electrical devices on and off in a building. It is typically used for security purposes such as making the building appear to be inhabited when you're out on a trip. For more information please contact the instructor.
Adaptive Content Web Server: Major news, sports, and trading web sites face a largely dynamic demand that can exhibit huge load spikes which produce periods of transient overload. Such overload, if not dealt with, can render the server unreachable. To deal with severe overload situations, many major sites, such as www.cnn.com, alter their content such that less is displayed when overload is expected thereby compensating for the increased demand. This is done by changing page size and the number of embedded objects (pictures) that appear in the page. The practice is called content degradation. For example, upon the September 11th attack on the World Trade Center, CNN experienced an unusual load surge and commensurately reduced their main page content, gradually returning to the usual format as load declined. The CNN page one hour later, seven hours later and one day later shows how the amount of content and embedded images was initially cut then increased as the load surge tapered off. The problem with this approach is that it's both manual and pessimistic. Content has to be chosen for the worst case load. It is impossible to switch to better content on a per-request basis depending on instantaneous load. The server would have to serve low quality content even if its capacity could have allowed most incoming clients to receive high quality content at the current demand level. This project develops an adaptive content web server. Given two versions of the same content that differ in the amount of detail, the server dynamically decides which version to serve to which fraction of clients at any given time depending on client importance and current load level. The goal is to maximize the quality of content served while avoiding overload. The idea is of particular relevance to e-commerce web cites, in which the apprearance of the page can be a main factor in whether or not the client decides to purchase the advertized product.