Send “SMALL IDEAS!” through a network. Delay a piece, lose another, and watch what the receiver can actually use.
Enable JavaScript to change the conditions and run the interactive experiment.
A message can travel in pieces through a network. IP carries packets; the transport protocol determines what the receiving application gets. TCP provides an ordered byte stream. UDP delivers datagrams without that same built-in guarantee.
TCP receives later bytes while an earlier piece is still missing. What does the application see?
TCP exposes the stream in order. Buffering later bytes avoids handing the application a hole in the stream. Select the missing-piece comparison and watch the buffer fill before repair.
This example places two message bytes in each TCP segment or UDP datagram, carried by an IP packet. Routers forward IP packets toward a destination. The displayed packet numbers are teaching labels; TCP sequence numbers count bytes, not “packet 1, packet 2”.
One delayed piece can arrive after later pieces. Our TCP receiver buffers later bytes and exposes only the contiguous stream from the beginning. A missing piece holds that stream back. The UDP view shows each datagram as it arrives; it adds no application-level repair.
In the selected first-loss case, the TCP sender retransmits the missing bytes after an illustrative timeout. The receiver then releases the now-contiguous data. Acknowledgments report the next expected byte, so their meaning is cumulative.
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.
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.
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.
Write SM, AL, L␣, ID, EA and S! on six slips. The ␣ mark stands for a space. Add starting byte labels 100, 102, 104, 106, 108 and 110.
Shuffle the slips and hold the 104 slip aside temporarily. Deliver the others. As the receiver, place arrived pieces in sequence and read only the uninterrupted beginning.
Return the missing slip. Read the complete message. Repeat, this time reading each slip immediately in arrival order to imitate a basic UDP application. Discuss what extra rules would be needed to reconstruct it.
Can you deliver a sentence correctly when its pieces arrive out of order?
A paper analogy for ordering and buffering. People do not reproduce network speeds, packet headers, congestion control or actual router algorithms.
RFC 9293 §2.2, §3.1, §3.4 and §3.8.1. Sequence numbers identify bytes; retransmission repairs losses. Our timeout is fixed and illustrative.
IETF · TCP, RFC 9293RFC 768, Introduction and Header Format. UDP contains ports, length and checksum rather than TCP sequence/ACK fields.
IETF · UDP, RFC 768RFC 791 §1.4 and §2.2. The lesson is a conceptual IP route map, not an IPv4 header or fragmentation implementation.
IETF · IP, RFC 791Independent subject review is pending.
Read the sources and model assumptionsClose a switch. Follow a complete path. Give current a second route and discover what changes.
Release a few virtual balls, then a thousand. Change the chance of a right turn and compare the results with a mathematical prediction.
Interactive explorationOpen a genuinely trained miniature Transformer. Change token tiles, inspect real attention and vector calculations, sample a continuation, and test the limits of a confident prediction.