reliable-transport/PROTOCOL.md

Stage 2: what crosses the wire

challenge.py speaks this for you. It is written down so that when something goes wrong you can tell a protocol mistake from a Go-Back-N or Selective Repeat mistake, which is the difference between "my JSON was wrong" and "my window logic was wrong". Only the second one is what this project is about.

There are two channels. Control is TCP and carries one JSON object per line. Data is UDP and carries exactly the packets packet.py builds, unchanged.

Control, on TCP 8422

client  {"msg": "hello", "challenge": "A-sr", "student": "tremaux"}
server  {"msg": "session", "challenge": "A-sr", "student": "tremaux",
         "udp_port": 8500, "bytes": 24000, "seconds": 90,
         "send": "the payload from payload_for(student), 24000 bytes"}
client  {"msg": "ready", "udp_port": 51234}
  ... the UDP transfer happens ...
server  {"msg": "result", "ok": true, "challenge": "A-sr",
         "flag": "CS4220-RT-A-sr-...", "detail": {...}}

challenge is one of A-gbn, A-sr, B-gbn, B-sr. student is your UCCS username in lowercase: it decides which payload you are asked for and which flag you get back, so a capture of someone else's session is no use to you.

udp_port in the session message is the port on the server to send to. udp_port in the ready message is the port your own socket is bound to, so the server knows where to send. Send ready only once your socket exists, because the server starts the moment it arrives.

On a refusal the server answers {"msg": "error", "detail": "..."} and closes. On a challenge that ran but did not complete it answers {"msg": "result", "ok": false, "reason": "...", "detail": {...}}. The reason is written to be useful: it says what the server saw, not just that you failed.

Data, on UDP

Exactly packet.py, with no additions:

type		seq means
0	DATA	which packet this is, from 0
1	ACK	cumulative for -gbn ("I have everything before seq"), individual for -sr ("I have seq")
2	FIN	how many data packets the sender sent
3	FINACK	the receiver has everything and is closing

Two things to know:

• A FINACK may carry a payload. packet.py has always allowed it and nothing else in this project uses it. In challenge A the server puts your flag there, so the flag arrives in band, on the data channel, as well as on the control channel. challenge.py keeps it for you and prints it in the trace as finack_payload.
• The path is deliberately awkward. The server drops about 5% of what it sends, duplicates about 3%, and holds about 5% back to arrive late. This is the same set of impairments channel.py simulates offline, so a protocol that passes selfcheck.py should survive it. The seed comes from your student id, so your run is reproducible if you want to dispute a result.

What the server is, and is not

It is a correct implementation of the receiver and the sender for both protocols, written from P&D 2.5 and not from your code. That is the whole point of Stage 2: selfcheck.py tests your sender against your receiver, and two halves written by the same person can agree with each other about a mistake.

It is not a grader. It does not see your source, and it has no opinion about your style. It answers one question: does your half interoperate with a half you did not write?