You and your team will design an application-layer protocol, write a specification for it, implement it, and then try to make your implementation talk to another team’s completely independent implementation of the same protocol.

Teams

You work in groups of 2 or 3, sharing one repository. Have your team formed by Week 4 (9/16), when we pick protocols in class.

  • Only one of you accepts through this link. Whoever goes first becomes the repository owner, and the repo is named after them. It doesn’t matter who — nothing else changes.
  • Everyone else must not accept. Accepting a second time creates a second, empty repository and splits your group.
  • The founder adds the others: https://classroom50.org → your assignment → Manage Group → Manage collaborators → type your teammate’s GitHub username → Add → Save collaborators.
  • Teammates get access immediately — there is no email to wait for. You are already members of the course GitHub organisation, so there is no invitation to accept. Check by opening https://github.com/gw-computer-networks-f26/csci4431-project1-app-protocol-<founder>: if it loads, you’re in.
  • Only the founder sees the assignment on classroom50.org. If you are a teammate, that page will look empty — expected, and it has no effect on your grade. Your group is graded from the founder’s repository and everyone with access to it gets the same score.
  • Then you all clone the same repository and work in it normally. Share one repository, and git pull before you start and again before you push — that is what keeps three people out of each other’s way.

At least two groups must build each protocol — otherwise there is nobody to interoperate with, and half the project cannot happen. Several groups picking the same protocol is fine, and makes pairing easier.

Claim your protocol on the board, link is here

Find the row for the protocol you want — or start a new row if it isn’t listed — and put your group in the first empty GROUP column, using your GitHub usernames:

PROTOCOL                  GROUP 1                    GROUP 2
------------------------  -------------------------  -------------------------
Key–value store           @alovelace + @aturing      @ghopper + @kthompson

Timeline

Phase What When
— Form your team By Week 4 · 9/16
— Choose a protocol and find a partner group In class, Week 4 · 9/16
1 Specification v1 — written by your team alone Due 9/23
2 Specification v2 — merged with your partner group In class Week 5 · 9/23, due 9/27
3 Implementation — client and server, following v2 Due 10/14
4 Interoperability session — your code meets theirs In class, Week 8 · 10/14
4 Reflection — what broke, and what you now think Due 10/18

Grading is weighted toward the writing, not the code: the two specifications are worth 40% together, the reflection 30%, the implementation 20%, and project management 10%.

Late submissions. A phase submitted after its due date loses 20% of that phase’s points for each day late, so a phase that is five days late earns nothing. The deduction applies to that phase only.

Using AI tools

The course AI policy applies to this project: AI tools are a supplement to your own thinking, not a replacement for it.

These are acceptable:

  • Asking an AI tool to explain a concept, or terminology from the book or slides.
  • Asking an AI tool to explain or help debug code that you have written.
  • Discussing your protocol’s design choices with an AI tool.
  • Checking grammar and improving the writing style or formatting of your spec or reflection.

These are never acceptable:

  • Asking an AI tool to design your protocol from the assignment description.
  • Having an AI tool write your specification, your implementation or your reflection for you.

The specifications and the reflection are graded on your decisions and what you observed when your code met your partner group’s. If you are unsure whether something is allowed, ask us first.

Ground rules

  • UDP only, and you may assume no loss and no reordering — every datagram arrives exactly once, in order. Reliability is Project 2’s problem.
  • Console applications. No GUI, no web frontend.
  • No real external data. Everything can be synthetic or hard-coded. A weather server inventing its forecasts is completely fine — the point is the protocol, not the data.

How much protocol is enough?

Your protocol must have:

  • At least four distinct message types, doing meaningfully different jobs.
  • At least one interaction spanning multiple messages, where what one side sends depends on what it received earlier.
  • At least two things that can go wrong at the application level — not network failures, which you’re assuming away, but things like a request for something that doesn’t exist, a request arriving at the wrong moment, or a value too large to send.

Protocol options

The table says what each protocol is for, not how it works. Deciding what the messages are, what they’re called and what comes back is the assignment. Each of these clears the bar above if you build the harder version — the third column is where the real design work is.

Protocol What it does What makes it hard
File sharing Clients move files to and from the server, and find out what it has A file larger than one datagram (~65 KB) has to be split up. You have to invent ordering, completion, and a way for the receiver to know it got everything. Also consider: overwriting, listing, and what a partial transfer leaves behind.
Chat / messaging Clients post messages in rooms, others read them How are clients addressed and messages delivered? Is history maintained?
Email-style server Users leave messages for each other and collect the ones addressed to them How to handle addressing, mailboxes, and message retention? What happens to mail for a user who doesn’t exist?
Music service Clients control playback of a playlist the server keeps (send lyrics as the “audio”) How to handle timing of playback? How to support multiple clients?
Key–value store Clients store and retrieve values the server holds on their behalf Consider more complex features like with expiry, conditional writes (“only if unchanged”), listing what’s there, and limits on how big a key or value may be.
Name resolver Maps names to things, from a table you invent One query type is trivial. Consider several kinds of record, answers with more than one result, names that resolve to other names, etc.
Weather service Returns fabricated conditions for a named place A single forecast for a single place is too simple. Consider extensions like multi-day forecasts, ranges of time, units the client asks for, etc.
Dialogue server Runs a scripted back-and-forth with the client — knock-knock jokes, a choose-your-own-adventure, a text adventure The exchange happens in a fixed order, so both sides must agree on whose turn it is and what a valid reply looks like at each step. What happens when the client says something unexpected mid-dialogue, or wanders off and comes back?
Turn-based game Two clients play through a server — hangman, connect four, battleship Pairing two players up, deciding whose turn it is, rejecting a move made out of turn, and agreeing on what “the game is over” means. Pick a game with real state; something decided in one move each is too small
Peer-to-peer chat Nodes talk directly, with no central server — each is both client and server Discovery: how does a node find the others? How ot handle clients changing over time?

You may propose something that isn’t on this list, on one condition: at least one other group must commit to building it too. Propose your idea on Discord before Phase 1 begins.