# Exercise 2 — Handshake and Reliability Mechanics

## Scenario

A teammate insists "TCP just magically makes sure nothing gets lost — I don't need to know how." You want to prove, with a worked trace, that TCP's reliability is a specific, inspectable mechanism, not magic — and that understanding it changes how you'd debug a real problem.

## Deliverables

1. **Handshake trace with sequence numbers.** A client opens a TCP connection to a server. The client's initial sequence number is `x = 5000`. The server's initial sequence number is `y = 9000`. Write out all three segments of the handshake (SYN, SYN-ACK, ACK), including the exact flags set and the exact `seq=` / `ack=` values at each step, following the mechanics described in the theory file's "Under the Hood" section.

2. **Loss and retransmission trace.** After the handshake above, the client sends 3 segments of data, each carrying 100 bytes, back to back (so, roughly, `seq=5001`, `seq=5101`, `seq=5201`). The second segment (`seq=5101`) is lost in transit. Describe, step by step, what the server does and does not receive, what ACK(s) the server sends back, and what the client does once it detects the gap (tie this to sequence numbers and retransmission, not a vague summary).

3. **The UDP counterfactual.** Rewrite the same 3-segment scenario from deliverable 2, but assume this was UDP instead of TCP (3 datagrams sent, the second one lost). Describe exactly what the receiving application actually sees, and state explicitly whether the receiver has any way to know a datagram was lost at all using UDP alone.

4. **Debugging implication.** A REST API client occasionally receives a response with a chunk of the JSON body missing in the middle, causing a parse error — but only over a flaky mobile network. Using what you now understand about TCP's guarantees, explain why "TCP normally prevents this exact failure mode" makes this bug worth investigating as something OTHER than ordinary packet loss (name at least one alternative real cause a TCP connection could still produce a truncated/corrupted-looking body, e.g. a timeout closing the connection mid-response, an intermediate proxy, or an application-level bug).

## Notes

- Show your sequence number arithmetic explicitly in deliverables 1 and 2 — don't just describe it in prose.