Final project

Overview

We have reached the end of the course, congratulations! Take a deep breath. You've made it.

In this course, we have discussed some of the core protocols and concepts that power the Internet. Yet, there are many topics we have not had time to cover. Though some of the core protocols will be around forever, networking is a fast-moving field of CS, with new protocols, ways to build applications, and new performance and security concerns evolving every day. Thus, our goal is to give you the tools you need to tackle new networking challenges you encounter.

In this project, you will have an opportunity to implement a protocol or concept we have discussed in class but did not get to do in our other projects. Examples could include building a client/server for a protocol we've discussed, or implementing a networked application in some interesting way. Your project could also extend an existing project we have already completed, so long as you propose a significant-enough extension.

See the Sample topics section for a list of possible topics. You are welcome to use any of these, modify them, or suggest your own! Any ideas you suggest do not need to fit into these two categories–-you can work on any topic you want, so long as we approve your idea.

Logistics and Timeline

Teams

You SHOULD work on the project in a team of 2. You MAY keep the same team as for IP/TCP, or you may form a new team. Working solo is permitted, but we don't recommend it unless you have extenuating circumstances or a very narrow project topic (ask Nick if you're unsure).

If you worked as a group of 3 for TCP, or if you had permission to work solo, you may continue to do so for this project.

Note: Regardless of your team situation, you MUST fill out the team preference form to register your team (even if it's a team of size 1), or ask to be matched to a team, by Tuesday, December 3 at 5pm EST.

All team mumbers must fill out the form–only mutual requests will be honored.

If you do not submit the form on time, we may not be able to match you to a team, requiring you to work solo.

Timeline

Your project has two deadlines:

A brief project proposal due by Friday, December 6 at 11:59pm. No late days may be used on this part, since we need to review your proposals and provide feedback.
Your final submission, including a your implementation and a brief writeup are due by Monday, December 16

Repository

Once your team has been formed, you will receive a github classroom link to create a repository.

This repository you receive will be completely blank. Since this is an open-ended project, there is no starter code or reference implementation–-this repository is just a place to keep your work and collaborate!

Languages

You can work on the project using any language(s) you want–-whatever you think will help you accomplish the project most easily. You are are NOT restricted to Go/C/C++/Rust: Python or other scripting languages are fine.

As with previous projects, you may also use any software libraries to help, so long as they do not trivialize the project you have proposed. For example, if your project is to build a DNS resolver, it's fine to use a library to build/parse DNS packets, so long as you write the actual logic to decide what to query and interpret the responses yourself.

Project proposal

To ensure your project has a suitable scope, you must write a short project proposal and submit it via Gradescope on or before Friday, December 6 by 11:59pm EST. No late days may be used on this part, since we need to review your work and provide feedback–any late submissions will incur a penalty.

Your proposal should be short (no more than 1–2 pages) and should include the following:

An outline of the project you want to implement–what do you want to acheive?
Any stretch goals you think may be difficult but nice to have
Any tools, libraries, or language(s) you intend to use (doesn't need to be a final list)
Any open questions you'd like us to help you answer

If you're not sure about all your project's details–that's okay! Let us know what you'd like to learn and how we can help.

Final implementation and writeup

When you are done, you will submit your work by pushing all code to your repository and submitting a final report and demo video that describe your overall results. The requirements for each part are described in the following sections.

Writeup: There is no official length requirement, but a reasonable estimate is on the order of 3–4 pages of text/figures. In general, your writeup should contain at least the following components:

Introduction: What were your overall project goals? What (briefly) did you achieve?
Design/Implementation: What did you build, and how does it work? For this part, give an overview of the major components of your system design and how they work, similar what you might write in a readme.
Discussion/Results: Describe any results you have, what you have learned, and any challenges you faced along the way. For this part, please include any relevant logs/screenshots of your program operating (and/or reference your demo video).
Conclusions/Future work: Overall, what have you learned? How did you feel about this project overall? If you could keep working on this project, what would you do next?

Demo video: In addition to your code and writeup, your final submission should include a short (no more than 5min) demo video to demonstrate your work. This can be as simple as a screen recording while you run your code, or a more involved presentation where you also describe your project and how it works. Basically, this is just a way to supplement your writeup in a video format–we will look at both when grading. If your video is too large to upload to your repo, please upload it to Google Drive and include a shareable link in your document.

Final Deadline

Your final submission (code, writeup, demo video) is due by Monday, December 16 at 11:59pm EST.

Warning: Late date days may be used on this project, and extensions can be granted in extenuating circumstances as usual. However, since this is the end of the semester, some extensions may not be possible, depending on your individual circumstances (graduation date, final grade logistics, etc.).

If you have concerns, you should contact Nick sooner rather than later!

Sample project topics

The following pages contain some sample project ideas. These are meant to be a starting point to think about your own project–you can use one of these, or pick your own!

Note: We'll be adding some more resource links soon!

DNS resolver

Relevant lectures: Lectures 17–18

Implement a DNS resolver that can perform recursive and iterative queries (ie, by starting with a root nameserver). Some extensions could include adding support for caching, or querying different record types (A, AAAA, TXT, …).

Some implementation details

You are not required to serialize DNS packets yourself. There are many good libraries that can do this for you. For Python, a good one is dnspython
For testing recursive queries, https://public-dns.info/ curates a list of public DNS servers around the world you can query
When sending DNS queries, don't send a huge number of queries to the same server in rapid succession–-otherwise you might get blocked! Instead, wait >=100ms in between queries.

Build a responsive web application

Relevant lectures: Lectures 19-21

Implement a web application of your choice that includes both static and dynamically-generated content, and a RESTful API to provide data. Some extensions could include using tools like websockets to have the server send data to clients asynchronously.

You can use any tools/frameworks you like, so long as your application can run on a local system (ie, no cloud-only deployments). In your writeup, you must be able to explain how your application uses your API and other HTTP technologies (websockets, etc.) to realize your application.

Build an application with RPCs, eg. a better Snowcast

Relevant lectures: Lecture 22

When we built Snowcast, you wrote code to manually compose messages in the Snowcast protocol format and send them along TCP sockets. This is a great exercise in implementing a protocol. However, modern applications often leverage frameworks to help build network APIs more quickly. One such framework is gRPC: users can define their API and message formats, and the gRPC framework automatically generates code for establishing connections, authentication, serializing messages and more, in your language of choice.

To explore these tools, you could implement part of Snowcast (or some other application of your choice) in gRPC, or some other framework that provides similar functionality. A good starting point might be to build a client and server that connects and exchanges Snowcast's Hello/Welcome messages, and then continue with selecting stations and streaming data.

Some implementation details

If you choose to implement Snowcast, note that you can modify the Snowcast protocol as much as you like–you don't need to stick to the same message formats, as long as your protocol achieves the same goals.
Some parts of Snowcast per our specification may not map well onto gRPC–one example is streaming via UDP. For these cases, it's up to you to decide how to handle it. Is there something similar you could do with gRPC, or do you need to make your own custom solution using plain sockets? What are the tradeoffs? Whatever you decide, document your decisions in your writeup.

HTTP API: ActivityPub

Relevant lectures: Lecture 22

Mastodon, the open-source, decentralized Twitter alternative, is built on the ActivityPub protocol (Overview, Full Specification), which is an HTTP API for exchanging messages between ActivityPub servers and clients. While ActivityPub has a lot of features, the mechanics essentially boil down to exchanging JSON messages via HTTP.

For this project, you could implement a basic ActivityPub client and server that support some basic methods. To do this, you can use any web programming libraries you like to serve HTTP endpoints. A good starting point would be to implement some methods from ActivityPub's "Social API", which specifies communication between clients and the server (posting and fetching messages). As a stretch goal, you could consider parts of its "Federation API", for communicating between your own servers to build a larger social network.

Build your own traffic analyzer

Wireshark and similar tools are great for viewing and analyzing network traffic, but you can also build your own custom packet analysis tool to answer very specific question. Using a packet capture library like scapy (Python), pcap (Go), or libpcap (C/C++), implement your own traffic analyzer that can either watch for packets on a live network interface, or read a capture file, to perform some specific analyses on your own traffic.

What should you analyze? You decide! Examples could include:

Extracting files and images from HTTP (not HTTPS) traffic
Logging your DNS traffic, and outputting a list of all domains queried from your system, how often you query them, etc.
Measuring average latency of TCP connections, or drawing your own TCP stream graphs to examine congestion control performance