Domain: Engineering — Network Engineering
Target concept: Four-way Handshake for TCP Connection Termination

Video generation prompt: An animation simulating the TCP protocol disconnection experiment, where a TCP client that has established a connection with a server actively closes the connection, with the transmission process of TCP messages marked by red waveforms.

Evaluation guide:
Target concept: TCP four-way handshake for active connection termination, a deterministic, stateful, bidirectional process where the client initiates closure by sending FIN, triggering a cascade of server ACK/FIN and final client ACK, culminating in TIME-WAIT. Minimum mechanistic assumptions: (i) TCP is connection-oriented and full-duplex; (ii) each endpoint maintains independent send/receive states; (iii) FIN consumes sequence space and signals EOF in that direction; (iv) TIME-WAIT prevents old duplicate segments from corrupting new connections. Expected phased storyline: Phase 1 (t=0–1.5s): Client emits FIN (red waveform C→S) → enters FIN-WAIT-1. Phase 2 (t=1.5–3.0s): Server receives FIN, emits ACK (red S→C) → enters CLOSE-WAIT; Client receives ACK → enters FIN-WAIT-2. Phase 3 (t=3.0–4.5s): Server emits FIN (red S→C) → enters LAST-ACK. Phase 4 (t=4.5–6.0s): Client receives FIN, emits ACK (red C→S) → enters TIME-WAIT (pulsing halo); Server receives ACK → enters CLOSED. Phase 5 (t=6.0–8.0s): TIME-WAIT expires → Client enters CLOSED. Visibility constraints: All red waveforms must be unambiguously tied to their segment; state badges must be legible and co-located with respective nodes; no occlusion or overlapping UI elements; camera perspective is static front-facing schematic (no zoom/rotation).

Manual:
I. Basic Demonstration Information
Demonstration Title: Four-way Handshake for TCP Connection Termination Demonstration
Subject: Engineering - Network Engineering - TCP Protocol
Demonstration Purpose: To visually simulate the TCP disconnection process where a client actively terminates a connection with a server, using red waveforms to mark each transmitted TCP segment; to reinforce understanding of the four-segment handshake (FIN, ACK, FIN, ACK), state transitions (ESTABLISHED → FIN-WAIT-1 → ... → CLOSED), and the asymmetry of active vs. passive closure.
II. Demonstration Carrier/Equipment
Core Carrier: Animated schematic with two labeled nodes — ‘TCP Client’ (left) and ‘TCP Server’ (right), connected by a bidirectional communication link.
Auxiliary Elements: Red sinusoidal waveforms (fixed frequency, amplitude, color #FF0000) overlaid on packet transmission events; TCP flag labels (FIN, ACK, FIN+ACK); connection state badges (ESTABLISHED, FIN-WAIT-1, CLOSE-WAIT, LAST-ACK, TIME-WAIT, CLOSED); directional arrows showing segment flow.
III. Demonstration Content Description
Layout: Client (left), Server (right), horizontal link. All labels legible, no occlusion.
State Control: Animation runs at 30 fps, total duration ≤10s. Each TCP segment transmission lasts exactly 1.5s, with red waveform active only during transmission. State badges update *instantly* upon segment arrival.
Sequence: (1) Client sends FIN → Client enters FIN-WAIT-1, Server enters CLOSE-WAIT; (2) Server replies ACK → Client enters FIN-WAIT-2; (3) Server sends FIN → Server enters LAST-ACK; (4) Client replies ACK → Both enter CLOSED. TIME-WAIT (2×MSL) visualized as pulsing halo around Client for 2s post-final ACK.
IV. Observation of Core Phenomena
Red Waveform Feature: Exactly four red waveforms, each appearing *only* on one segment transmission, starting at source node center, traveling along arrow, ending at destination node center. Color is pure red (#FF0000), no hue shift.
Segment Order & Direction: Strict sequence: [C→S: FIN], [S→C: ACK], [S→C: FIN], [C→S: ACK]. Arrows never reverse direction or overlap incorrectly.
State Transition Fidelity: Every state badge appears *only* when triggered by correct incoming segment and vanishes *only* upon next transition. No skipped or duplicated states.
V. Summary of Key Knowledge Points and Principles
Core Concept: TCP connection termination requires four segments due to full-duplex nature — each direction must be closed independently; the active closer (client) enters TIME-WAIT to handle delayed duplicates.
Principle of Visual Recognition: Red waveform serves as a deterministic, temporally bounded visual marker for *packet-in-transit* — its presence, color, location, and timing directly encode protocol semantics (what, who, when, why). Absence of red = no transmission; red = active segment propagation; direction of red path = segment direction; sequence of red pulses = handshake order.

Prompt Grounding rubric:
level_1: No TCP-termination animation appears at all: no client/server labels, no red waveforms, no sequence of messages; the client, server, and packet objects are missing or unidentifiable, and the timeline instead shows something unrelated (e.g., HTTP traffic, UDP bursts, or a static image).
level_2: The animation shows generic back-and-forth arrows but no clear client-initiated closing sequence; red waveforms are missing or attached to the wrong elements (e.g., a background or a label); the client and server are unlabeled or mislabeled (e.g., 'server' appears on the left); at most one TCP segment is visible and the order is not recognizable.
level_3: The client and server are labeled and placed on opposite sides of the frame; red waveforms mark some but not all transmitted messages (e.g., only the FIN, not the ACKs); two or three of the four handshake segments are shown, but one is missing or the direction is wrong (e.g., the server sends the first FIN); the overall order is partly right but has an inversion (e.g., an ACK shown before its FIN).
level_4: All four handshake segments are present in order (client FIN, server ACK, server FIN, client ACK), each correctly labeled and directionally arrowed; a red waveform marks every one of the four segments; the client is shown initiating (first FIN reads 'Client → Server'); the layout is clear (client left, server right); only one small flaw remains, such as a waveform that looks slightly orange rather than pure red or one ACK label sitting slightly off its arrow.
level_5: Full visual alignment with the prompt: (i) 'TCP Client' (left) and 'TCP Server' (right) are clearly labeled; (ii) exactly four red waveforms appear, each one overlaid on a single segment's transmission; (iii) each waveform starts as its packet is sent; (iv) the order is exactly [Client→Server: FIN] → [Server→Client: ACK] → [Server→Client: FIN] → [Client→Server: ACK]; (v) all four waveforms share the same style (red, smooth, similar amplitude and duration), with no stray signals or clutter on screen.

Scientific and Causal Correctness rubric:
level_1: No causal relationship is shown: the messages appear all at once or in a random order, the connection state stays at 'ESTABLISHED' the whole time with no change, there's no sign of either side half-closing or the connection ending, and the waveforms have no evident link to any specific TCP event.
level_2: Connection-state changes appear but without proper cause (e.g., a 'CLOSED' label shows up before the final ACK is sent); waveforms appear but don't track the right flag (e.g., a red waveform on a SYN packet); at least one segment breaks TCP's own logic (e.g., the server sends its FIN before it has acknowledged the client's FIN); there's no visual sign of the 'half-closed' state at all.
level_3: The causal chain is partly shown: the client's FIN visibly triggers the server's ACK, and the final ACK leads to 'CLOSED' labels on both sides; but the half-close in between is missing (no 'FIN-WAIT' or 'TIME-WAIT' style state indicator appears), the waveform timing is only loosely tied to the events (e.g., it starts noticeably after the arrow it belongs to begins moving), and the server's own FIN doesn't look clearly prompted by having received the client's ACK.
level_4: The causal chain is mostly complete: the client's FIN is immediately followed by the server's ACK (with a state label change on the server side); the server's own FIN follows that ACK (with another server-side state change); the client's final ACK completes the exchange (with both sides ending in a 'CLOSED'-type label); red waveforms begin right as each packet is sent and last only for the transmission; the half-closed state is visually distinguished somehow (e.g., a different border or badge on the server); one minor piece is missing, such as no visible 'TIME-WAIT' indicator on the client side.
level_5: The full six-state causal chain is shown and scientifically complete: on the client side, ESTABLISHED leads to a FIN-sent state, then an ACK-received state, then a TIME-WAIT-style state (shown, e.g., as a fading highlight) after the final ACK; on the server side, ESTABLISHED leads to a CLOSE-WAIT-style state after receiving the client's FIN+ACK, then a LAST-ACK-style state after sending its own FIN, then CLOSED; each state change is visibly triggered only by the matching incoming segment; each of the four waveforms appears exactly once, starts at its source node, and ends at its destination node; there is no ACK shown without a prior FIN, and no state change without a matching segment causing it.

Spatiotemporal Consistency rubric:
level_1: Severe spatiotemporal breakdown: the client and server icons swap positions mid-animation; a waveform floats in empty space with no visible source or destination node; a timestamp or state label appears to jump backward; a packet arrow seems to teleport partway along its path; the motion stutters badly (very choppy, far below smooth playback); or the four waveforms have wildly inconsistent durations (some much shorter or longer than others).
level_2: Spatial inconsistency: the client and server icons change size inconsistently between frames; a waveform's starting point sits noticeably off from the node it's supposed to originate from; a long, unexplained pause (much longer than the others) separates two segments that should follow close together; a waveform stays on screen well after its packet should have arrived; or a state label flickers on and off without a smooth transition.
level_3: Mostly consistent: the client and server stay fixed on the left and right; each waveform starts near its node's center and travels along a straight path to the other node; the gaps between segments look roughly even to the eye; minor flaws remain, such as one waveform slightly overshooting its destination node, or one state label disappearing a bit too abruptly.
level_4: High spatiotemporal fidelity: the client and server icons stay fixed in position, size, and orientation; every red waveform visibly launches from its source node, follows its arrow smoothly, and arrives at its destination node; the gaps between the four segments look evenly spaced to the eye; state labels fade in and out smoothly rather than snapping; the only flaw is a brief, noticeable overlap where one segment's fade-in begins a little before the previous segment's effect has fully cleared.
level_5: Full spatiotemporal integrity across the whole clip: the client and server nodes stay in the same on-screen position and size throughout; each of the four red waveforms visibly starts at its source node and ends at its destination node, following the same path as its arrow; every state-badge change happens only once its corresponding waveform has visibly arrived, and before the next segment's waveform begins; the four segments look evenly spaced in time with no segment noticeably faster or slower than the others; and there is no flicker, jump, or sudden resizing of any node, arrow, or label.