CS744 Course Project

Back to CS 744 home page


Project Overview

The goal of the project is to build a real computer system to apply the system design and engineering principles learnt in class. The project will run in multiple phases throughout the semester. Below are tentative deadlines for the various phases. Phase 0 does not carry any grade, and each of Phase 1 through 4 will account for ~10% of your grade (a total of 40% for the project).

Phase 0: Project Proposal, defining the system, forming teams.

In phase 0, you will finalize the system you will build, and pick your teammates. While you are free to pick a system of your choice to build, the following constraints will ensure that your system meets a certain minimum level of complexity.

Some examples of systems you can build:

  1. A file server with a backend authentication database. When a client connects to the server, it must first send a request to authenticate/login. The frontend server requests a username and password and checks with the backend database to authenticate the user. The client can then request files from the frontend server, which are served from the server's memory or disk.
  2. A web server with a front end proxy cache. When a client requests a webpage, a front end proxy cache checks if a cached copy of the file is available. In case of a cache miss, the proxy must go to the backend and fetch the webpage. Otherwise, the file is served from the front end's memory or disk.
  3. A file/web server with a front end load balancer. The front end receives the request, fetches the file from one of the backend servers, and replies to the client.
  4. A simple ticket/room reservation system, where the client issues requests to check availability or book tickets, the backend database holds the reservation data, and the frontend server fetches information from the backend and replies to the reservation request.
  5. A key-value store, with a stateless frontend, and the key-value pairs distributed across one or more backend servers. The frontend server redirects the request to one of the backends depending on the value of the key.
  6. A chat/messenger application. A user logs in to the front end and sends/receives messages through a client side application. Multiple users connected to the front end can send and receive messages to each other using their usernames or some other identifier. The server front end authenticates users and forwards messages for those users that are online, while the backend server stores messages for users that are offline. The front end must retrieve offline messages from the backend when the user logs in.
  7. A simple gaming application, where the user logs in and sends commands/actions via the client side application, and the front end handles these requests. The users of a game can also communicate with each other via the front end. The backend can be used to keep scores or other such book keeping information.

Of course, the examples above are only suggestions, and you are free to pick anything that is not on the list as well. We only require that your system look realistic, and have a reasonable amount of complexity to make your project interesting. However, there is no need to make your system compatible with existing standard application protocols. For example, if you are building a web server, you can use your own simplified HTTP header formats at the client and server, and your server need not be compatible with real life HTTP clients.

Submission instructions

We will circulate an online form to you, where you must fill in your team information and a brief description of the system you propose to build. Your project team must have no more than 2 members.

Your project description must contain the following information:

Please limit your description to 2-3 paragraphs, but be as specific as possible in your proposal, so that we get a clear picture of what you plan to do. If we have any feedback and need you to modify your system in any way, we will get in touch with you within a week.

Note that you are not bound by this proposal, and you may tweak (but, hopefully, not fully overhaul) your system design in the later phases as you notice things to fix while coding. The goal of the intial proposal is only to get you started with thinking about the design, and to provide early feedback where needed.

Note that submission of proposals by the deadline for Phase 0 is mandatory. This phase of the project carries no weightage in terms of grade.


Phase 1: A simple prototype

In phase 1, you will build a simple prototype of your system. You will build the client and the multiple server tiers. Your servers must be able to handle multiple clients concurrently.

You will need to make a few design choices in this phase, like the architecture (multiprocess / multithreaded with master-worker configuration / event-based) to use at the server tiers. Your client can be an interactive program with as fancy a user interface as you like, in order to showcase all the features of your system. The goal of this phase is correctness: multiple concurrent clients should be able to send requests and obtain responses correctly from the server.

Submission instructions

You must create a tar gzipped file, with the filename being the roll numbers of all the team members separated by an underscore ("_"). The tarball should contain the following:

Grading instructions

Your project submission will be graded in a 15-minute demo by the TAs. You will need to set your system up using your submitted code on our lab machines (running Ubuntu 16.04) during the demo. Please provide enough scripts (e.g., to load data into your database) to ensure that the system can be setup quickly in the given demo slot. If you are using a database like mysql, make sure that the name of the database and the login credentials can be changed easily to avoid conflict with the other teams.

We will grade your project phase 1 on three aspects: the clarity of your report (the functionality of the system should be clearly escribed), the correct working of your system in handling each type of request defined, and the ability of your system to handle multiple requests concurrently.


Phase 2: Load testing

In phase 2, you will perform a load test of your system. You will first write a multithreaded load generator that simulates multiple clients (in place of a single client that sends one request at a time) to bombard your server tiers with multiple requests in parallel. Your simulated clients in the load generator should not have any interactivity (e.g., solicit user input, or pause to think between requests), but must bombard requests to the server in an automated fashion. Your load test can be an open loop or a closed loop test. The parameters to your load generator must be the number of concurrent users (in the case of closed loop) or the rate of requests per second (in the case of open loop). You may also have other inputs to the load generator like the server IP, port, and the duration over which the load test should be performed. Here are some tips on how you can run a load test correctly. The outcome of your load test should be a characterization of your server's performance (throughput and response time) as a function of increasing levels of load, and an identification of the saturation throughput of your server and the bottleneck resource at saturation. You may also profile your code to verify that the bottleneck you observe is indeed justified.

Submission instructions

For phase 2 of your project, you must submit all your code and scripts on Moodle, much like in phase 1, to enable us to conduct a demo and see your code working. In addition to your code, you are required to submit a report containing the following: This phase of your project will be graded by reading over your report (primarily) and by conducting a demo and/or reading your code.

Phase 3: Evaluating design alternatives and optimizing system performance.

Note: some of the teams could not finish phase 2 correctly. For such teams, please do a thorough job of load testing itself as part of phase 3. The majority of the teams that finished phase 2 successfully can go ahead and read the rest of the guidelines for phase 3.

In this phase, you will work on one of two things: you can either apply some of the techniques learnt in class to optimize the performance of your system, or you can reimplement your system using an alternate design and evaluate multiple design choices. Some possible ideas are listed below.

Whichever path you choose, you must perform a load test on your optimized/alternate design much like in phase 2, and compare the performance of the two versions of your design. You must explain the difference in performance observed, and the justifications for why the performane changed or didn't change.

Note that the most important thing in this phase of the project is to think creatively about your system and try out new ideas learnt in class. Please do not be afraid of a negative result (no performance improvement). It is ok to try something new and not find any performance improvement, as long as you understand and can justify why performance didn't improve.

Submission instructions

You must submit your code and a report (describing your optimizations and their impact) on Moodle.

This phase of the project will be primarily graded via demo. You will showcase your entire system that you have built over the three phases. The TAs will ask you to run and demonstrate the performance of your system to verify that you have successfully built your system, optimized it (to the best of your abilities), and tested its performance. Please submit all code, scripts, installation instructions, and other details of your system to enable the TAs to fully evaluate your system.


Phase 4: Final presentation and viva

You will not be writing any new code in the final phase of your project. The goal of this phase is to test that you have actually understood the systems concepts involved in your project, and to verify that all team members have contributed constructively to the project. In the final phase of your project, you will prepare a short presentation describing your complete system (the basic design, any optimizations you have done, your load generator, and so on) and your results (initial performance, performance after optimizations, and so on). You should prepare no more than 10 slides, and your presentation should be under 10 minutes. You must sign up for a slot to make your presentation. After the presentation, each member of the team will be asked about their contribution to the project, and questioned on the components they have contributed to.

Submission instructions

A form will be circulated to signup for presentation slots.

Good luck!

Back to CS 744 home page