Simulate TCP and UDP behaviour

Inject loss, reordering and retransmission into a bounded simulation, then separate transport arrival from application acceptance.

Packet Pat: I want you to trace arrival, ordering, retry and application acceptance as separate decisions., your practice guide

Packet Pat: I want you to trace arrival, ordering, retry and application acceptance as separate decisions.
Predict the reading, then compare it with the measurement.

Python 3 in your browser (JupyterLite)

Python · no install

Inject loss, reordering and retransmission into a bounded simulation, then separate transport arrival from application acceptance.

Tier 2 · Web · paste-in setup · No account

Version tested: Python 3.12.7 / Pyodide 0.27.6 in JupyterLite 0.6.4; Chromium 148.0.7778.96; captureSource playwright:jupyterlite. Date: 2026-09-10.

Open the notebook in your browser and run each Python cell; no install or account is needed.

Three ways to run: use JupyterLite here with no install; run main.py locally from the downloadable lab folder; or open the same notebook in Google Colab.

Open in your browser (new tab)

Steps

Screens captured against Python 3 in your browser (JupyterLite) Python 3.12.7 / Pyodide 0.27.6 in JupyterLite 0.6.4; Chromium 148.0.7778.96; captureSource playwright:jupyterlite on 2026-09-10; the tool may have moved on — the text steps are the contract.

  1. Step 1

    Do
    Run the setup and freeze the five-message logical-time experiment.
    You will see
    The notebook states the seed, message count, simulation boundary and application acceptance rule.
    Why it matters
    Explicit assumptions keep simulated behavior separate from a packet capture.

  2. Step 2

    Do
    Inject one UDP loss and one reorder event.
    You will see
    The arrival table shows D4 missing and D3 arriving before D2.
    Why it matters
    UDP preserves datagram boundaries but does not promise delivery or order.

  3. Step 3

    Do
    Apply a sequence gate to the UDP arrivals.
    You will see
    D3 is held until D2 arrives, while D5 remains held because D4 is absent.
    Why it matters
    Transport receipt and application acceptance are different events.

  4. Step 4

    Do
    Model TCP recovery of the missing fourth message.
    You will see
    The table delivers all five messages and records one retransmission.
    Why it matters
    TCP repairs the ordered byte stream before exposing later bytes.

  5. Step 5

    Do
    Measure head-of-line delay for D5.
    You will see
    D5 waits 48 logical milliseconds behind retransmitted D4.
    Why it matters
    Ordered delivery can add latency even when later bytes already arrived.

  6. Step 6

    Do
    Run a bounded CoAP-style confirmable retry.
    You will see
    Two attempts produce one accepted action through a duplicate cache.
    Why it matters
    Retry ownership and idempotency are application concerns above UDP.

  7. Step 7

    Do
    Review the model limits and deployment decision.
    You will see
    The final trace names omitted kernel, congestion, radio and timing behavior.
    Why it matters
    A simulation explains mechanisms but cannot replace testing the actual path.

Chapter checks

These questions refer to the chapter’s examples. Use the return links to review their answers.

  1. A learner says TCP is like a phone call, so the receiver must understand every application message. What should the reviewer clarify?

    Return to the chapter’s knowledge check

  2. A cold-room cloud service opens a TCP connection to the gateway and sends a compressor-setpoint command, then claims the compressor accepted the new state. What is the best review response?

    Return to the chapter’s knowledge check

Return to Practice: Transport Analogies · Browse Labs