Final project :email: - HedgeDoc

<style> details { margin-top: 0.5em; margin-bottom: 0.5em; } summary { //font-weight: bolder; } summary:hover { text-decoration: underline; } blockquote { font-size: 16px; } //h3{border-bottom: 2px solid black;} section { padding: 0em 1em; padding-bottom: 1em; padding-top: 1em; border-radius: 4px; background-color: #f7f7f7; border: 1px solid #ccc; } .todo { color: #ff00ff; border: 2px dashed #ff00ff; padding: 0em 1em; border-radius: 5px; margin-top: 1em; margin-bottom: 1em; //display: none; // UNCOMMENT TO HIDE TODOs } </style> **[« Back to the main CSCI1680 website](https://brown-csci1680.github.io)** # Final project :globe_with_meridians:  **Key deadlines** - **[Team registration form](https://forms.gle/yMSm41CmEMdDnYz4A)**: Wednesday, April 22 at 11:59pm EDT - **Brief project proposal**: Monday, April 27 at 11:59pm EDT (no late days!) - **Final submission**: Friday, May 8 at 11:59pm EDT   ## Overview We have reached the end of the course, congratulations! Take a deep breath. You've made it. :grin: 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](#Sample-project-topics) section for a list of possible topics. You are welcome to use any of these, modify them, or suggest your own! 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. :::warning :warning: **Note**: Regardless of your team situation, **you `MUST` fill out the [team registration form](https://forms.gle/8kdJ5EZbGgGC1GNK7)** to register your team (even if it's a team of size 1), or ask to be matched to a team, by **Wednesday, April 22 at 11:59pm EDT** If this deadline is problematic for you, please let us know. All team mumbers must fill out the form--only mutual requests will be honored. ::: ### Timeline Your project has two deadlines: - A brief **project proposal** due by **Monday, April 27 at 11:59pm EDT**. **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 **Friday, May 8 at 11:59pm EDT** ### 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 server, 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. This policy also has a more relaxed AI policy than the rest of the course -- for details see [AI policy](#AI-Policy).  ### Expected workload The final project is meant to be a small, proof-of-concept to get experience with something you haven't had the chance to try yet. Ideally, the goal is for it to be just enough work to learn something useful, but not so much that it becomes tedious--your implementation doesn't need to particularly rigorous or polished, but you should aim for something that "works" end-to-end based on the goals you set in your proposal. In terms of relative workload, **this project should take less time than Snowcast**--a reasonable estimate for an A-level final project is 10-15 hours of work (assuming ~20-30 hours for Snowcast, by comparison). Our requirements are pretty open-ended so that you can spend these hours in a way that interests you, but it doesn't need to be a ton of work. You are, of course, welcome to spend more time if you find yourself enjoying it, or you want to make something extra cool for your Github profile (see below!), but this isn't required. ### Publishing your work Typically, course collaboration policies prevent you from publishing your work after the course ends, since it could be used by future generations of students. However, since this project is very open-ended, you `MAY` publish your work publicly (e.g., on your public github page). As you read the [Sample topics](#Sample-topics), or think about your own idea, we encourage you to think of something that you find interesting or fun, and make it your own! We can help advise on scope for your proposal.  ### AI Policy This project has a modified (and more relaxed) AI policy than the rest of the course, to let you build a larger project than you could otherwise, help avoid certain parts of the implementation that may not be the main focus of what you want to learn. Overall, you may use any AI tools you like to write code for you, so long as you can demonstrate that you (not an agent) are putting ~10 hours of learning effort into the task. Here are some guidelines: - In your project proposal, you should sketch which parts of the project you would like to have AI build for you, and what you want to implement yourself---which should be the part you want to learn. - We'll provide feedback on this when you submit your proposal. Depending on how much you want to build with AI, we might ask you to add more features, or to analyze or test certain things in your writeup to demonstrate that the AI code works, and make sure you get the learning benefit by critically examining what it produced. - Your project submission will also include a brief writeup about your work. **You `MUST` create the writeup on your own** (as a team). In your writeup, you'll be asked to talk about your experience with AI, and provide an analysis/critique of what the agent produced and where you needed to intervene.  If you want to publish your work publicly, we *especially* encourage you to take this policy seriously: use it as an opportunity to learn how to build something *with* AI, rather than just a way to get something you can turn in. *(Consider: in the current era of AI, which do you think a recruiter would value more?)* ### 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 **Monday, April 27 at 11:59pm EDT**. **No late days may be used** on this part, since we need to review your work and provide feedback. If you don't think you can make this deadline, please email Nick. :::success **If you have your proposal ready earlier**, we encourage you to submit sooner! Nick will check Gradescope periodically and try to provide early feedback. ::: 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 to build, and what do you want to learn from it? - 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) - How you plan to use AI to help you - 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. Similarly, if you're not sure if the topic you've proposed is too big or too small, that's also okay! When we give feedback, we'll be primarily advising on scope: if we think you have specified something too large, we'll suggest ways you can simplify things (i.e., goals that you should convert to "stretch goals"); if we think you need more, we'll ask you to add more features. Please just sketch out what you're thinking, and we'll help you draw the line on what would be a viable project. ### 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). If you build parts of your project with AI tools, you should discuss your experience: in the end, where did the AI do well, and where did you need to intervene, and how do you know your project works as it describes? - **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 **Friday, May 8**. :::warning **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! ::: #### Submitting your work To submit your work, please do the following: 1. Push your code, writeup, and video to your Github repository. If your video is too large to add to your repo, please upload it to Google Drive and include a share-able link in your writeup instead 2. Upload your repository to the "Final Project" assignment on Gradescope - Please note: The gradescope submission will filter out all files in your repository *except* text/PDF/markdown/video files--this is normal. Depending on your project topic, your repository may end up with a lot of files, which can break Gradescope. The filter lets us see your writeup files on Gradescope (which helps us with grading), we'll clone your repo from Github for the rest. Owing to the end of the semester, there is no interactive grading for this project by default. If we have any major questions about your work that we can't learn from your writeup, the instructor may ask to meet with you before your grade is finalized. If you have left campus, such a meeting would occur via Zoom. # 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!   ### Build your own DNS server Relevant lectures: Lectures 17--18 Implement a DNS resolver that can perform recursive and iterative queries (i.e., by starting with a root nameserver) for your computer. To begin, start by writing a program that can resolve DNS queries from a command-line argument, then extend your program to become a server by listening on a UDP port for real DNS queries that you make with a tool like `dig` or `nslookup`. As a final test, set your computer's DNS settings to use your server, and watch it resolve queries for your whole system! Some extensions could include: - Caching - Blocking for certain domains (e.g., build your own DNS-based ad blocker) - Feel free to express other ideas! <details><summary>Some implementation details </summary> - 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`](https://www.dnspython.org/) - 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, you can wait >= 100ms between queries, keep a list of servers that you query in a round-robin manner, and/or use caching! - To run a DNS server for your host system, you would likely need to implement queries for at least the following record types: `A`, `AAAA`, `TXT`, and `SRV` </details> ### 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 and demonstrate (e.g., via screenshots) 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](https://grpc.io): 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](https://grpc.io), 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. <details><summary>Some implementation details </summary> - 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. </details> ### ActivityPub Relevant lectures: Lecture 22 Mastodon, the open-source, decentralized Twitter alternative, is built on the ActivityPub protocol ([Overview](https://en.wikipedia.org/wiki/ActivityPub), [Full Specification](https://www.w3.org/TR/2018/REC-activitypub-20180123/)), 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](https://scapy.net/) (Python), [pcap](https://pkg.go.dev/github.com/google/gopacket/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](https://www.packetsafari.com/blog/2021/10/31/wireshark-tcp-graphs/) to examine congestion control performance