Think twice / 08
The Night Post
A postcard for someone across the water. Four envelopes. A postal service with a few… habits.
Send something and see ↓How to play
You send a four-piece postcard along an unreliable route. Envelopes can arrive late, out of order or more than once; some never arrive. Your goal is a complete picture at the receiver and enough confirmation for the sender to stop retrying. Then see how much extra post that assurance costs.
- Press Send and run to start the plain delivery. Tick Start paused before sending if you want to control every turn. Use Next turn to inspect arrivals and the sender's knowledge separately, or Skip to the result to complete the attempt.
- Tick Number the pieces and send again. Every attempt uses the same route. Inspect which gaps and copies the receiver can now recognise, and whether the postcard is actually complete.
- Add Ask for receipts, then retry. Let the attempt finish and compare the receiver's completion, the sender's confirmations and total envelopes sent. Compare three-turn and eight-turn waits. Aim for a complete, confirmed delivery, then explain the cost of making it faster.
What to notice
Four envelopes arrive, but two contain the same piece of a postcard. The receiver still lacks part of the picture. Numbering the envelopes reveals the missing piece, but cannot deliver it. The sender has a different problem: silence does not tell them whether an envelope was lost or its receipt went missing.
Send the postcard through the plain route first. Then add numbers, followed by receipts and retries. Keep two outcomes separate: did the receiver complete the picture, and does the sender know it? A shorter retry wait can recover a lost piece sooner, but it can also send an extra copy of something merely delayed.
TCP uses sequence numbers, acknowledgements and retransmission to make an ordered byte stream from unreliable transmissions. This postcard is a small analogy with fixed waits, not a model of the full protocol. Real TCP adjusts its timers and has other machinery this room leaves out.
The distinction also matters beyond networks. If an API request loses its connection, the action may already have happened. Trying again can repeat it; the application needs its own protection against that. A delivery receipt cannot prove a person read a message or that a payment committed. How much extra post does it take to deliver the picture and let its sender know?
Read more: TCP: sequence numbers and acknowledgements · HTTP: safe retries.
Get the picture home
Ready for the night routeTry the first delivery as it is. Then add a fix and send it through the same night again.
The sender
Across the waterWish you were here.
The night route
Nothing on the road yet.
Delays, a lost envelope, an extra copy. Fixed conditions on every replay.
The receiver
Waiting by the harbourA space on the mantelpiece.
Setting up the local post desk.
Start with the plain delivery. No fixes selected.
Changing a delivery rule prepares a fresh attempt. Your finished comparisons stay below.
Same night. Different rules.
Your last six finished attempts. Every one starts with the same four pieces and the same postal schedule.
| Your rules | Whole at receiver | Sender has all receipts | Envelopes sent |
|---|
Open the postal log (nothing sent yet)
A view of the whole route for you, including losses. The sender only sees arriving receipts and its own sends, never this log.
Rules & model
The postcard and the receiver
One postcard has four picture strips, sent together at turn 0. Without numbers, the receiver places strips in arrival order, with overflow beside the picture. With numbers, it puts each strip in its matching slot and sets extra copies aside. It never reads the sender’s original to fill a gap or repair the order. The whole-picture check compares the actual received arrangement with the original; it is an observer’s check, not extra information sent to the receiver.
The fixed night route
For the original four sends, strip 3 arrives at turn 1, strip 2 is lost at turn 2, strip 1 arrives at turn 3, a postal copy of strip 3 arrives at turn 4, and strip 4 arrives at turn 6. Every retry takes two turns and arrives once. Nothing is corrupted. This is the entire route, not random failures or a schedule that changes to defeat your choices.
Receipts and retrying
Receipts require numbering and are sent for every arriving numbered envelope, including extra copies. A receipt normally takes two turns to return. The receipt for strip 1’s original delivery is lost one turn after it is sent. Other receipts arrive. Each piece without an arrived receipt is retried after 3, 5 or 8 turns since its last send, according to your choice. Arrivals are processed before retry decisions on each turn. The sender does not inspect loss events, receiver slots or future arrivals. A receipt for an earlier attempt still confirms that piece.
When a delivery ends
The sender stops creating retries once all four receipts have arrived. Already travelling envelopes and their receipts finish their journeys before the trial ends. Without receipts, it ends when the original postbag has cleared. There is also an 18-turn safety limit. The result records when the picture first became whole and, separately, when the sender received all four confirmations. The envelope count includes every original send, retry and receipt, including lost ones. The postal copy is tracked as an arrival, not charged as a sender’s extra send.
What this leaves out
There are no acknowledgements of receipts, bandwidth queues, changing routes, corrupted content, encryption or real network connections. The route deliberately makes both missing pieces and missing confirmations visible. Choosing another waiting time tests this schedule; it does not prove an optimal timeout for the internet. Everything runs locally on this page. Comparisons last for this visit only, up to six attempts. Running pauses when the page is hidden and requires a deliberate resume.