TCP Three-Way Handshake Sequencer

TCP's defining claim is that it is connection-oriented, and this activity is where that word stops being a label and becomes a sequence of observable events. The module's TCP Connections lesson frames it as a life cycle — establish, communicate, tear down — and that framing is the spine of the ordering here. A student who can name SYN, SYN-ACK and ACK but cannot say what each one changes has memorised a chant rather than learned a protocol. The cards therefore carry no step numbers. If they did, the activity would collapse into sorting integers and the student would never touch the knowledge the objectives name. Each card gives the flag state and the sending host instead, so the order has to be reasoned out. Two rules are sufficient, and stating them as rules rather than as eight separate facts is the point. The flags say what a message is for: SYN opens a connection by synchronising sequence numbers, ACK confirms what has already been received, FIN announces that the sender has finished sending. The direction says when a message can occur, because a host can only acknowledge something that already reached it. Together they fix the whole order without any card needing to be labelled. Establishment runs three steps. The client sets SYN to 1 and ACK to 0 — there is nothing to acknowledge yet — and picks a random initial sequence number, which is the value being synchronised. The server answers with both bits set, because it is doing two jobs in one segment: SYN to agree, and ACK to bring the acknowledgment number into use, carrying the client's sequence number plus one as the next byte it expects. It also chooses its own random starting number, so both directions end up numbered. The client's closing ACK sets SYN back to 0 and confirms synchronisation, and at that point both parties have agreed to communicate and agreed what the numbering is. Then the payload moves, sequence numbers counting up by the bytes sent with acknowledgements travelling back along the way. Termination is where the useful difficulty sits, and it is why this set has eight cards rather than the six a symmetrical reading would suggest. The tempting misconception is that teardown mirrors the handshake — a FIN and a combined FIN-ACK, three steps down as there were three steps up. It generally does not, and the lesson is explicit that the standard exchange is four steps: FIN, acknowledgement, FIN, acknowledgement. The reason is worth teaching directly. The middle segment of the handshake can merge two jobs because both hosts want the connection open at the same moment. Termination has no such coincidence: each host stops having data to send on its own schedule, so a FIN closes only the direction of the host that sent it. The client's FIN says the client is done, the server acknowledges that it heard so, and only when the server itself has finished does it send its own FIN for the client to acknowledge. Reading a FIN as an instruction to shut down rather than as a statement about the sender's own data is the error underneath most wrong orderings here, and the card text names the direction precisely so that the distinction is recoverable rather than a trick. The three-step variant does exist, where the middle acknowledgement rides along with the server's own FIN, and it is mentioned on the final card so the student who has seen one in a capture is not left thinking the activity is wrong. It is framed as the compressed case rather than the norm, which matches both the lesson and what a Wireshark capture in the module's DEMO lessons typically shows. All eight cards are presented every run rather than sampled. The domain is a single life cycle, and a life cycle with steps missing is not a shorter version of the same object — the entire skill being assessed is the completeness and order of the sequence. This activity pairs naturally with the module's TCP Header lesson, which supplies the flag fields the cards refer to, and with the Wireshark TCP Connections demo, where the same eight events appear as real captured segments. It is the mechanism-level companion to the module's TCP vs UDP Scenario Sorter: that one asks when a connection is worth setting up, this one asks what setting one up actually consists of. Running them interleaved with other module content works better than running them back to back.