Operate the stream lab
Use the four tabs to change one condition at a time. The examples illustrate protocol behavior. They do not measure network performance.
Open the stream lab in a separate page.
On narrow screens, scroll inside the lab to reach the lower controls.
Experiment 1: four streams, then eight
- Select 4 or 8 streams and keep Packet loss selected.
- Drop the selected packet and observe the missing and buffered byte ranges.
- Recover the bytes and compare the recovery packet number with the lost packet number.
- Select 8 streams and Two streams for the packet contents.
- Drop that packet and count the streams with gaps.
- Select Packet reordering and repeat the experiment.
Expected result: loss belongs to packets; delivery order belongs to streams
Expected result: loss belongs to packets; delivery order belongs to streams
A packet can carry frames from several streams. Losing the selected packet creates a gap in each affected stream.
Each affected stream buffers its later bytes. Unaffected streams can deliver contiguous received bytes.
Recovery sends the missing ranges in a new packet with a new number. Their stream offsets remain the same.
In the reordering example, the original delayed packet fills the gap without a retransmission.
All streams still share congestion control. The application can introduce further dependencies.
Experiment 2: reassemble a byte stream
- Select Offsets and FIN.
- Receive offsets 4–7 before offsets 0–3.
- Receive FIN at offset 8 while the earlier bytes are still missing.
- Receive offsets 0–3, then receive that range again.
Expected result: received, readable, and finished are different states
Expected result: received, readable, and finished are different states
The first four received bytes wait behind a gap. They are buffered but not yet available in order.
FIN declares a final size of eight bytes. It does not supply the missing data.
After the earlier range arrives, all eight bytes become readable and the receiving direction can finish.
The duplicate does not create four additional application bytes.
Experiment 3: exhaust two different allowances
- Select Limits and reset.
- Send four bytes on A twice. Observe A’s exhausted stream allowance.
- Send four bytes on B. Observe the exhausted connection allowance.
- Add four bytes of A credit. Observe that A still cannot send.
- Add eight bytes of connection credit, then send on A.
- Reset A’s sending direction and check B’s state.
Expected result: both allowances must permit a send
Expected result: both allowances must permit a send
A starts with eight bytes of stream credit. B can still send after A reaches that limit.
Once their combined use reaches twelve bytes, the connection allowance blocks additional stream bytes.
Increasing A’s stream limit alone does not increase the connection limit.
Resetting A ends that sending direction. Its final size remains part of connection accounting, and B remains open.
The experiment assumes that congestion control permits each illustrated send.
Experiment 4: decode a stream ID
Select Stream IDs and compare the four combinations of initiator and direction.
A bidirectional stream has separate offsets and flow-control state for each sending direction.
FIN finishes one direction normally. RESET_STREAM abandons one sending direction; STOP_SENDING asks the peer to stop its sending direction.
These actions do not require the entire connection to close.
Completion check: explain why a blocked stream, an exhausted connection allowance, and a lost packet require different observations.