A local, deterministic event model. No real network traffic is sent and no browsing or personal message data is inspected.
Two preset routes illustrate possible forwarding paths; packets are not randomly routed at every hop by actual TCP. Delays are prescribed, not measured internet latency.
Timeout and ACK animation are deliberately simplified. This is not an RFC-conformant TCP implementation, throughput benchmark or packet capture.
UDP chunk order labels belong to this application demonstration; UDP itself has no TCP-style sequence or acknowledgment field.
Inspect the byte numbers: The displayed starting data sequence number is 100. Six two-byte chunks start at 100, 102, 104, 106, 108 and 110. After all twelve bytes are received contiguously, the next expected byte is 112. Connection establishment is assumed complete.
A bounded event model: Initial sends are 0.35 s apart; the normal one-way duration is 2 s. The selected second chunk can be delayed by 0–4 s. Only the first attempt of chunk 3 can be lost. Its optional TCP retry starts 5 s after its initial send, with an illustrative 0.8 s ACK return delay.
Reliability is a design choice: UDP applications can add their own ordering, repair or newer transport protocols. TCP does not promise delivery under every failure; it can eventually report a broken connection. Congestion control, adaptive retransmission timing, handshakes, encryption and real routing decisions are outside this visualization.
What has been checked
Analytical reference cases, conservation or transition invariants, finite drawing commands, bounded setup parsing, discovery and route integrity are checked automatically. These checks do not establish anatomical fidelity, learner outcomes or browser/device compatibility. Independent subject review, learner trials, comprehensive accessibility review and browser video encoding checks remain pending.
Each source supports the associated claim. Sources do not certify this implementation or its visuals.