TCP keeps data flowing even when the network drops packets. Set a loss rate and a timeout, then run the simulation to watch packets get lost, time out and be sent again until they arrive.
This simulator models how one reliable connection copes with an unreliable network. The sender hands over one data packet at a time, the network may quietly throw some away, and the receiver answers each packet that survives with a short acknowledgement, an ACK.
Because a sender cannot hear silence, it uses a timer. If no ACK comes back within the retransmission timeout, the packet is assumed lost and the same data is sent again â the heart of TCP's reliability.
The two sliders are the two real trade-offs. The loss rate sets how hostile the network is, and the timeout sets how patient the sender is. A very short timeout recovers quickly but fires needlessly; a very long one wastes time before noticing a real loss.
Run the simulation at different settings and read the log: it shows every send, drop, timeout and ACK in order, so you can see how loss turns into delay.
The sender takes the next packet from its send queue and puts it on the wire. Its sequence number is logged so every attempt can be told apart.
Based on the loss rate you set, the packet either crosses the network or is lost. A loss is drawn as the packet turning red and stopping in the middle: it never reaches the receiver.
No acknowledgement arrives for a lost packet, so the sender simply waits. After the retransmission timeout expires it concludes the packet was lost rather than merely slow.
The sender resends the same data with the same sequence number. This repeats as many times as needed: the receiver can recognise a duplicate and keep only one copy.
When a packet finally gets through, the receiver stores it, sends an ACK back and the sender moves on to the next sequence number. The stream stays complete even though individual packets were lost.
It is the chance, from 0 to 100 percent, that any single packet is dropped by the network. At 20 percent roughly one in five packets never reaches the receiver and has to be sent again.
It is how long the sender waits for an acknowledgement before assuming a packet was lost and sending it again. A short RTO reacts fast but may resend too eagerly; a long RTO wastes time before recovering.
If no acknowledgement arrives in time, the sender cannot tell a lost packet from a slow one, so it assumes the worst and retransmits. It keeps the same sequence number, so the receiver can spot a duplicate.
An ACK, short for acknowledgement, is the small reply the receiver sends back to confirm that it got a packet. Reaching the sender, it tells the sender that this packet is safe and the next one can go.
No. A dropped packet simply never arrives. The data is only at risk if a packet is corrupted in transit rather than lost, which is why TCP also carries checksums and drops damaged packets.
Not exactly. Real TCP pipelines many packets at once, uses sliding windows and adaptive timers. This model shows one packet at a time and a fixed timeout, so it is a teaching simplification.