@classytic/stage 0.3.0 → 0.4.0

package/dist/networking/models/encapsulation.mjs

@@ -0,0 +1,132 @@
+//#region src/networking/models/encapsulation.ts
+/** Outermost last: this is the order the headers are ADDED going down the stack. */
+const HEADERS = [
+	{
+		kind: "application",
+		protocol: "HTTP",
+		bytes: 0,
+		addressing: null,
+		answers: "What is being asked for. This is the message itself, not a wrapper."
+	},
+	{
+		kind: "transport",
+		protocol: "TCP",
+		bytes: 20,
+		addressing: "port",
+		answers: "Which program on the machine, and where this piece fits in the stream."
+	},
+	{
+		kind: "network",
+		protocol: "IPv4",
+		bytes: 20,
+		addressing: "IP address",
+		answers: "Which machine, anywhere. Set once by the sender and carried the whole way."
+	},
+	{
+		kind: "data-link",
+		protocol: "Ethernet",
+		bytes: 18,
+		trailerBytes: 4,
+		addressing: "MAC address",
+		answers: "Which box on THIS wire takes it next. Replaced at every routed hop."
+	}
+];
+const OVERHEAD_BYTES = HEADERS.reduce((sum, header) => sum + header.bytes, 0);
+/** Wrap a payload in the first `depth` headers. Full depth is the frame that goes on the wire. */
+function encapsulate(payloadBytes, depth = HEADERS.length) {
+	const applied = HEADERS.slice(0, Math.max(0, Math.min(depth, HEADERS.length)));
+	const overheadBytes = applied.reduce((sum, header) => sum + header.bytes, 0);
+	const onWireBytes = payloadBytes + overheadBytes;
+	return {
+		payloadBytes,
+		headers: applied,
+		depth: applied.length,
+		onWireBytes,
+		overheadBytes,
+		overheadShare: onWireBytes === 0 ? 0 : overheadBytes / onWireBytes
+	};
+}
+/** Unwrap one layer. The payload is never touched, which is the point. */
+const decapsulate = (state) => encapsulate(state.payloadBytes, Math.max(0, state.depth - 1));
+/** How deep a device opens the frame before it can do its job. */
+const opensTo = (kind) => kind === "switch" ? "data-link" : kind === "router" ? "network" : "application";
+/**
+* Split a path at its layer-3 boundaries. A switch forwards a frame without terminating it, so it
+* does not start a new segment. A router does, because it builds a brand new frame for the next
+* wire. The number of segments is therefore routers + 1, however many switches are in the way.
+*/
+function segmentsOf(path) {
+	const boundaries = path.filter((node) => node.kind !== "switch");
+	const segments = [];
+	for (let index = 0; index < boundaries.length - 1; index++) {
+		const from = boundaries[index];
+		const to = boundaries[index + 1];
+		const through = path.slice(path.indexOf(from) + 1, path.indexOf(to)).filter((n) => n.kind === "switch");
+		segments.push({
+			from,
+			to,
+			fromMac: from.mac,
+			toMac: to.mac,
+			through
+		});
+	}
+	return segments;
+}
+function frameOn(segment, source, destination) {
+	const rebuilt = segment.from.kind === "router";
+	return {
+		segment,
+		mac: {
+			from: segment.fromMac,
+			to: segment.toMac
+		},
+		ip: {
+			from: source.ip ?? "",
+			to: destination.ip ?? ""
+		},
+		note: rebuilt ? `${segment.from.name} threw away the frame it received and built a new one for this wire. Same packet inside, new MAC addresses outside.` : `${segment.from.name} addresses the frame to ${segment.to.name}, the next box on this wire, not to the far end.`
+	};
+}
+/** Every frame the message travels in, end to end. */
+const journey = (path) => {
+	const source = path[0];
+	const destination = path[path.length - 1];
+	return segmentsOf(path).map((segment) => frameOn(segment, source, destination));
+};
+const DEFAULT_PATH = [
+	{
+		id: "laptop",
+		name: "Laptop",
+		kind: "host",
+		mac: "AA:01",
+		ip: "10.1.0.20"
+	},
+	{
+		id: "switch",
+		name: "Switch",
+		kind: "switch",
+		mac: "SW:00"
+	},
+	{
+		id: "r1",
+		name: "Router 1",
+		kind: "router",
+		mac: "BB:11"
+	},
+	{
+		id: "r2",
+		name: "Router 2",
+		kind: "router",
+		mac: "CC:22"
+	},
+	{
+		id: "server",
+		name: "Server",
+		kind: "host",
+		mac: "DD:33",
+		ip: "10.9.0.7"
+	}
+];
+
+//#endregion
+export { DEFAULT_PATH, HEADERS, OVERHEAD_BYTES, decapsulate, encapsulate, frameOn, journey, opensTo, segmentsOf };

package/dist/networking/models/handover.d.mts

@@ -0,0 +1,116 @@
+import { Terrain } from "./cellular.mjs";
+
+//#region src/networking/models/handover.d.ts
+/** A mast beside a straight road, positioned by how far along the road it stands. */
+interface Mast {
+  id: string;
+  label: string;
+  /** Distance along the road, in km. */
+  atKm: number;
+  /** Perpendicular offset from the road, in km. Keeps the signal finite as the car passes. */
+  offsetKm?: number;
+}
+interface DriveOptions {
+  /** How much better a neighbour must be before the call moves, in dB. The whole lesson. */
+  marginDb: number;
+  /** Where the drive starts along the road, in km. Defaults to the beginning. */
+  fromKm?: number;
+  /** Where it ends, in km. */
+  roadKm: number;
+  megahertz: number;
+  terrain: Terrain;
+  /** Standard deviation of the shadow fading, in dB. 6 is a normal urban figure. */
+  shadowDb?: number;
+  /** How far the shadowing persists, in km. */
+  correlationKm?: number;
+  stepKm?: number;
+  seed?: number;
+}
+interface DriveSample {
+  xKm: number;
+  /** Signal from every mast at this point, in dBm, in the order the masts were given. */
+  rssi: number[];
+  /** Index of the mast currently holding the call. */
+  serving: number;
+}
+interface HandoverEvent {
+  atKm: number;
+  from: number;
+  to: number;
+}
+interface DriveResult {
+  samples: DriveSample[];
+  events: HandoverEvent[];
+  /** The weakest signal the call was actually held on. What the listener hears. */
+  worstServingDbm: number;
+  /**
+   * Times the call actually dropped: a SUSTAINED loss, not a momentary dip.
+   *
+   * Counting every sample below sensitivity makes a single shadow from a single building look like a
+   * dropped call, and then every setting of the margin looks equally broken. A call survives a brief
+   * fade; it dies when coverage is gone for long enough that the link cannot be maintained.
+   */
+  dropouts: number;
+}
+/**
+ * How far the car must travel with no usable signal before the call is counted as dropped, in km.
+ *
+ * A hundred metres at city speed is a few seconds of silence, which is where a caller hangs up. Any
+ * shorter and a single building's shadow registers as a dropped call; any longer and a genuine
+ * coverage hole is scored as a good link.
+ */
+declare const DROP_AFTER_KM = 0.1;
+declare const DEFAULT_DRIVE: Required<Pick<DriveOptions, "shadowDb" | "correlationKm" | "stepKm" | "seed">>;
+/**
+ * Drive the road and hand the call over as the rule dictates.
+ *
+ * The rule is deliberately the real one and nothing more: switch when some neighbour beats the
+ * serving mast by `marginDb`. Real networks add a time-to-trigger as well, so a neighbour must stay
+ * better for a while before anything happens. Leaving that out keeps ONE control on screen, and the
+ * margin alone already produces both failure modes a learner needs to meet.
+ */
+declare function drive(masts: readonly Mast[], options: DriveOptions): DriveResult;
+/**
+ * A road with two masts at either end, which is the smallest arrangement that has a boundary.
+ *
+ * One boundary is all this lesson needs. Adding a third mast produces more handovers without adding
+ * an idea, and makes the figure harder to read at the exact place a learner is meant to be looking.
+ */
+declare const TWO_MAST_ROAD: Mast[];
+/**
+ * The stretch actually driven, in km, which is NOT the whole road.
+ *
+ * The masts are eleven kilometres apart so that the midpoint sits near the edge of both cells: any
+ * closer and an absurd margin merely degrades the call without ever dropping it, any further and the
+ * call drops at every margin, which says nothing about hysteresis.
+ *
+ * But the drive covers only the five kilometres around the boundary, because that is where the whole
+ * phenomenon lives and because of what happens when it is drawn. Shadowing decorrelates over roughly
+ * a hundred metres. Across the full eleven kilometres that is one percent of the figure, so the
+ * signals render as static and a learner sees noise instead of two curves passing each other. Across
+ * five kilometres the same physics reads as visible undulation, and the crossings that cause the
+ * ping-pong can actually be counted. A real drive test covers the boundary for the same reason: it
+ * is the only part where the answer is in doubt.
+ */
+declare const DRIVE_WINDOW: {
+  readonly fromKm: 3.5;
+  readonly toKm: 8.5;
+};
+/** How a chosen margin actually performed, in the two terms it trades between. */
+interface MarginVerdict {
+  handovers: number;
+  worstServingDbm: number;
+  dropouts: number;
+  /** Plain-language reading of the trade, which is what the learner should leave with. */
+  verdict: "ping-pong" | "balanced" | "clinging";
+}
+/**
+ * Judge a margin on both of the things it trades between at once.
+ *
+ * Reporting only the handover count would make a huge margin look perfect, and reporting only the
+ * signal would make a margin of zero look perfect. Both numbers together are the only honest summary,
+ * and they are what makes the middle findable.
+ */
+declare function judgeMargin(masts: readonly Mast[], options: DriveOptions, runs?: number): MarginVerdict;
+//#endregion
+export { DEFAULT_DRIVE, DRIVE_WINDOW, DROP_AFTER_KM, DriveOptions, DriveResult, DriveSample, HandoverEvent, MarginVerdict, Mast, TWO_MAST_ROAD, drive, judgeMargin };

package/dist/networking/models/handover.mjs

@@ -0,0 +1,209 @@
+import { HANDSET_SENSITIVITY_DBM, rssiFromMast } from "./cellular.mjs";
+
+//#region src/networking/models/handover.ts
+/**
+* Handover: how a call survives a moving car.
+*
+* Chapter 2 treats a phone as standing still, which is the one assumption that makes cellular look
+* simple. Everything interesting starts when it moves. A call is held by ONE mast at a time, the
+* phone drives out of that mast's reach, and the call has to be passed to the next one without a gap
+* the listener can hear.
+*
+* The naive rule is "switch to whichever mast is strongest". It is the obvious rule and it fails
+* badly, for a reason worth meeting: near a cell boundary the two signals are almost equal, and
+* shadowing from buildings makes which one is stronger flip back and forth. A phone following that
+* rule hands the call over dozens of times across a few hundred metres. Each handover costs
+* signalling on both masts, and enough of them collapse a network that is otherwise fine. The name
+* for it is the ping-pong effect.
+*
+* The fix is a margin, called hysteresis: do not switch until the neighbour is better by some number
+* of decibels. That kills the ping-pong, and it is not free. A large margin means the phone clings
+* to a mast it has already driven away from, so the signal it is actually holding gets worse and the
+* call gets closer to dropping. There is no setting that is simply correct, which is the real lesson:
+* this is a tuned trade between signalling load and call quality, and a learner should find the
+* middle by overshooting in both directions.
+*
+* The fading here is spatially CORRELATED rather than redrawn at every sample. Shadowing comes from
+* buildings and terrain, so it persists over tens of metres; independent noise per sample would
+* produce a ping-pong that is an artefact of the sampling rate rather than of the physics, and would
+* quietly teach that the effect is worse than it is.
+*/
+/** Deterministic PRNG, because a lab that renders differently on the server than in the browser is broken. */
+function mulberry32(seed) {
+	let a = seed >>> 0;
+	return () => {
+		a = a + 1831565813 >>> 0;
+		let t = Math.imul(a ^ a >>> 15, 1 | a);
+		t = t + Math.imul(t ^ t >>> 7, 61 | t) ^ t;
+		return ((t ^ t >>> 14) >>> 0) / 4294967296;
+	};
+}
+const smoothstep = (t) => t * t * (3 - 2 * t);
+/**
+* Shadow fading along the road: one value per correlation length, smoothly interpolated between.
+*
+* This is what a building casting a radio shadow looks like from a moving car. It matters that it is
+* smooth: the ping-pong this lab teaches must come from two signals genuinely crossing each other
+* several times, not from a value that is redrawn every time we happen to look at it.
+*/
+function shadowField(seed, roadKm, correlationKm, sigmaDb) {
+	const random = mulberry32(seed);
+	const nodes = [];
+	const count = Math.ceil(roadKm / correlationKm) + 3;
+	for (let index = 0; index < count; index++) nodes.push((random() + random() + random() - 1.5) * 2 * sigmaDb);
+	return (x) => {
+		const scaled = Math.max(0, x) / correlationKm;
+		const index = Math.min(nodes.length - 2, Math.floor(scaled));
+		const t = smoothstep(Math.min(1, Math.max(0, scaled - index)));
+		return nodes[index] * (1 - t) + nodes[index + 1] * t;
+	};
+}
+/**
+* How far the car must travel with no usable signal before the call is counted as dropped, in km.
+*
+* A hundred metres at city speed is a few seconds of silence, which is where a caller hangs up. Any
+* shorter and a single building's shadow registers as a dropped call; any longer and a genuine
+* coverage hole is scored as a good link.
+*/
+const DROP_AFTER_KM = .1;
+const DEFAULT_DRIVE = {
+	shadowDb: 6,
+	correlationKm: .12,
+	stepKm: .02,
+	seed: 20260915
+};
+/**
+* Drive the road and hand the call over as the rule dictates.
+*
+* The rule is deliberately the real one and nothing more: switch when some neighbour beats the
+* serving mast by `marginDb`. Real networks add a time-to-trigger as well, so a neighbour must stay
+* better for a while before anything happens. Leaving that out keeps ONE control on screen, and the
+* margin alone already produces both failure modes a learner needs to meet.
+*/
+function drive(masts, options) {
+	const { shadowDb, correlationKm, stepKm, seed } = {
+		...DEFAULT_DRIVE,
+		...options
+	};
+	const fields = masts.map((_, index) => shadowField(seed + index * 7919, options.roadKm, correlationKm, shadowDb));
+	const levels = (x) => masts.map((mast, index) => {
+		const along = x - mast.atKm;
+		const offset = mast.offsetKm ?? .05;
+		return rssiFromMast(Math.hypot(along, offset), options.megahertz, options.terrain) + fields[index](x);
+	});
+	const samples = [];
+	const events = [];
+	let serving = 0;
+	let worstServingDbm = Infinity;
+	let dropouts = 0;
+	let belowRunKm = 0;
+	let counted = false;
+	const first = levels(options.fromKm ?? 0);
+	serving = first.indexOf(Math.max(...first));
+	const startKm = options.fromKm ?? 0;
+	for (let x = startKm; x <= options.roadKm + 1e-9; x += stepKm) {
+		const rssi = levels(x);
+		let challenger = serving;
+		for (let index = 0; index < rssi.length; index++) if (index !== serving && rssi[index] > rssi[challenger] + (challenger === serving ? options.marginDb : 0)) challenger = index;
+		if (challenger !== serving) {
+			events.push({
+				atKm: x,
+				from: serving,
+				to: challenger
+			});
+			serving = challenger;
+		}
+		const held = rssi[serving];
+		if (held < worstServingDbm) worstServingDbm = held;
+		if (held < -100) {
+			belowRunKm += stepKm;
+			if (!counted && belowRunKm >= .1) {
+				dropouts++;
+				counted = true;
+			}
+		} else {
+			belowRunKm = 0;
+			counted = false;
+		}
+		samples.push({
+			xKm: x,
+			rssi,
+			serving
+		});
+	}
+	return {
+		samples,
+		events,
+		worstServingDbm,
+		dropouts
+	};
+}
+/**
+* A road with two masts at either end, which is the smallest arrangement that has a boundary.
+*
+* One boundary is all this lesson needs. Adding a third mast produces more handovers without adding
+* an idea, and makes the figure harder to read at the exact place a learner is meant to be looking.
+*/
+const TWO_MAST_ROAD = [{
+	id: "west",
+	label: "West mast",
+	atKm: .5,
+	offsetKm: .08
+}, {
+	id: "east",
+	label: "East mast",
+	atKm: 11.5,
+	offsetKm: .08
+}];
+/**
+* The stretch actually driven, in km, which is NOT the whole road.
+*
+* The masts are eleven kilometres apart so that the midpoint sits near the edge of both cells: any
+* closer and an absurd margin merely degrades the call without ever dropping it, any further and the
+* call drops at every margin, which says nothing about hysteresis.
+*
+* But the drive covers only the five kilometres around the boundary, because that is where the whole
+* phenomenon lives and because of what happens when it is drawn. Shadowing decorrelates over roughly
+* a hundred metres. Across the full eleven kilometres that is one percent of the figure, so the
+* signals render as static and a learner sees noise instead of two curves passing each other. Across
+* five kilometres the same physics reads as visible undulation, and the crossings that cause the
+* ping-pong can actually be counted. A real drive test covers the boundary for the same reason: it
+* is the only part where the answer is in doubt.
+*/
+const DRIVE_WINDOW = {
+	fromKm: 3.5,
+	toKm: 8.5
+};
+/**
+* Judge a margin on both of the things it trades between at once.
+*
+* Reporting only the handover count would make a huge margin look perfect, and reporting only the
+* signal would make a margin of zero look perfect. Both numbers together are the only honest summary,
+* and they are what makes the middle findable.
+*/
+function judgeMargin(masts, options, runs = 5) {
+	let handovers = 0;
+	let dropouts = 0;
+	let worstServingDbm = 0;
+	for (let run = 0; run < runs; run++) {
+		const result = drive(masts, {
+			...options,
+			seed: (options.seed ?? DEFAULT_DRIVE.seed) + run * 104729
+		});
+		handovers += result.events.length;
+		dropouts += result.dropouts;
+		worstServingDbm += result.worstServingDbm;
+	}
+	const meanHandovers = handovers / runs;
+	const meanDropouts = dropouts / runs;
+	const verdict = meanHandovers > 4 ? "ping-pong" : meanDropouts > .5 ? "clinging" : "balanced";
+	return {
+		handovers: Math.round(meanHandovers),
+		worstServingDbm: worstServingDbm / runs,
+		dropouts: Math.round(meanDropouts),
+		verdict
+	};
+}
+
+//#endregion
+export { DEFAULT_DRIVE, DRIVE_WINDOW, DROP_AFTER_KM, TWO_MAST_ROAD, drive, judgeMargin };

package/dist/networking/models/handshake.d.mts

@@ -0,0 +1,90 @@
+//#region src/networking/models/handshake.d.ts
+/**
+ * Opening a TCP connection, and what it costs before a single byte of yours moves.
+ *
+ * The three-way handshake is usually taught as a ritual: SYN, SYN-ACK, ACK, learn the order, move on.
+ * Taught that way it answers none of the three questions a student actually has, and every one of
+ * them has a good answer.
+ *
+ * WHY THREE. Because each side has a sequence number the other must confirm, and a confirmation can
+ * only ride on a message. Two messages confirm one direction. The client learns the server got its
+ * number when the SYN-ACK arrives; the server learns nothing until the third message. A two-way
+ * handshake leaves the server holding a connection it cannot know the client agreed to, which is
+ * also, incidentally, how a SYN flood works.
+ *
+ * WHAT IT COSTS. One full round trip before the first request can even be sent. On a link with a
+ * 200 ms round trip that is 200 ms of nothing, every time, and it is why QUIC and TLS 1.3 went to so
+ * much trouble to fold the handshake into fewer trips. A learner who has watched the ladder stretch
+ * understands the entire motivation for a decade of protocol design.
+ *
+ * WHAT HAPPENS WHEN ONE IS LOST. Nothing, for a long time. There is no third party to notice, so the
+ * sender waits out a retransmission timeout that starts around a second, which is five times the
+ * round trip on a good link and utterly dominates. That asymmetry, a lost packet costing far more
+ * than a slow one, is the thing that makes loss and latency different problems.
+ */
+type Side = "client" | "server";
+/** Which segment of the handshake to lose, or none. */
+type DropWhich = "none" | "syn" | "syn-ack" | "ack";
+interface TcpSegment {
+  id: string;
+  from: Side;
+  /** The flags a packet capture would show. */
+  flags: string[];
+  seq: number;
+  ack: number | null;
+  /** When it left, in ms from the first attempt. */
+  sentMs: number;
+  /** When it arrived, or null if it never did. */
+  arrivesMs: number | null;
+  /** True when this is a second attempt after a timeout. */
+  retransmit: boolean;
+}
+interface HandshakeResult {
+  segments: TcpSegment[];
+  /** When the client may send its first request, in ms. */
+  readyMs: number;
+  /** When the server considers the connection open, in ms. */
+  serverOpenMs: number;
+  /** Time lost purely to waiting out a timeout. */
+  timeoutCostMs: number;
+  /** State of each side over time, for the column labels. */
+  states: {
+    side: Side;
+    atMs: number;
+    state: string;
+  }[];
+}
+interface HandshakeOptions {
+  /** Round trip time of the link, in ms. */
+  rttMs: number;
+  drop?: DropWhich;
+  /** Initial retransmission timeout, in ms. One second is the specified starting value. */
+  rtoMs?: number;
+}
+/** The specified initial retransmission timeout. Deliberately long, and the reason loss hurts. */
+declare const DEFAULT_RTO_MS = 1000;
+/**
+ * Run the handshake and return every segment with the time it left and the time it landed.
+ *
+ * Times are exact rather than simulated tick by tick, because the whole point is the arithmetic: one
+ * way is half a round trip, so the client is ready after one full round trip and the server half a
+ * trip later. Drawing that from a clock rather than from a formula would invite the reader to think
+ * the numbers came from somewhere mysterious.
+ */
+declare function handshake({
+  rttMs,
+  drop,
+  rtoMs
+}: HandshakeOptions): HandshakeResult;
+/** Total time before the first response could come back: the handshake, then the request and reply. */
+declare const firstResponseMs: (result: HandshakeResult, rttMs: number) => number;
+interface DropSpec {
+  id: DropWhich;
+  label: string;
+  /** Who notices the loss, which is the interesting part. */
+  noticedBy: string;
+  note: string;
+}
+declare const DROPS: Record<DropWhich, DropSpec>;
+//#endregion
+export { DEFAULT_RTO_MS, DROPS, DropSpec, DropWhich, HandshakeOptions, HandshakeResult, Side, TcpSegment, firstResponseMs, handshake };

package/dist/networking/models/handshake.mjs

@@ -0,0 +1,122 @@
+//#region src/networking/models/handshake.ts
+/** The specified initial retransmission timeout. Deliberately long, and the reason loss hurts. */
+const DEFAULT_RTO_MS = 1e3;
+/** Sequence numbers are random in practice; fixed here so the figure is readable and stable. */
+const CLIENT_ISN = 1e3;
+const SERVER_ISN = 5e3;
+/**
+* Run the handshake and return every segment with the time it left and the time it landed.
+*
+* Times are exact rather than simulated tick by tick, because the whole point is the arithmetic: one
+* way is half a round trip, so the client is ready after one full round trip and the server half a
+* trip later. Drawing that from a clock rather than from a formula would invite the reader to think
+* the numbers came from somewhere mysterious.
+*/
+function handshake({ rttMs, drop = "none", rtoMs = DEFAULT_RTO_MS }) {
+	const hop = rttMs / 2;
+	const segments = [];
+	const states = [{
+		side: "client",
+		atMs: 0,
+		state: "CLOSED"
+	}, {
+		side: "server",
+		atMs: 0,
+		state: "LISTEN"
+	}];
+	let timeoutCostMs = 0;
+	let clock = 0;
+	const send = (id, from, flags, seq, ack, sentMs, lost, retransmit = false) => {
+		const segment = {
+			id,
+			from,
+			flags,
+			seq,
+			ack,
+			sentMs,
+			arrivesMs: lost ? null : sentMs + hop,
+			retransmit
+		};
+		segments.push(segment);
+		return segment;
+	};
+	let syn = send("syn", "client", ["SYN"], CLIENT_ISN, null, clock, drop === "syn");
+	states.push({
+		side: "client",
+		atMs: clock,
+		state: "SYN-SENT"
+	});
+	if (drop === "syn") {
+		clock += rtoMs;
+		timeoutCostMs += rtoMs;
+		syn = send("syn-2", "client", ["SYN"], CLIENT_ISN, null, clock, false, true);
+	}
+	const synArrives = syn.arrivesMs;
+	states.push({
+		side: "server",
+		atMs: synArrives,
+		state: "SYN-RECEIVED"
+	});
+	let synAck = send("syn-ack", "server", ["SYN", "ACK"], SERVER_ISN, 1001, synArrives, drop === "syn-ack");
+	if (drop === "syn-ack") {
+		const retryAt = syn.sentMs + rtoMs;
+		timeoutCostMs += retryAt - syn.sentMs;
+		synAck = send("syn-ack-2", "server", ["SYN", "ACK"], SERVER_ISN, 1001, send("syn-2", "client", ["SYN"], CLIENT_ISN, null, retryAt, false, true).arrivesMs, false, true);
+	}
+	const synAckArrives = synAck.arrivesMs;
+	states.push({
+		side: "client",
+		atMs: synAckArrives,
+		state: "ESTABLISHED"
+	});
+	let ack = send("ack", "client", ["ACK"], 1001, 5001, synAckArrives, drop === "ack");
+	if (drop === "ack") {
+		const serverRetryAt = synAck.sentMs + rtoMs;
+		timeoutCostMs += serverRetryAt - synAck.sentMs;
+		ack = send("ack-2", "client", ["ACK"], 1001, 5001, send("syn-ack-2", "server", ["SYN", "ACK"], SERVER_ISN, 1001, serverRetryAt, false, true).arrivesMs, false, true);
+	}
+	const ackArrives = ack.arrivesMs;
+	states.push({
+		side: "server",
+		atMs: ackArrives,
+		state: "ESTABLISHED"
+	});
+	return {
+		segments,
+		readyMs: synAckArrives,
+		serverOpenMs: ackArrives,
+		timeoutCostMs,
+		states
+	};
+}
+/** Total time before the first response could come back: the handshake, then the request and reply. */
+const firstResponseMs = (result, rttMs) => result.readyMs + rttMs;
+const DROPS = {
+	none: {
+		id: "none",
+		label: "Nothing lost",
+		noticedBy: "nobody",
+		note: "Three segments, one and a half round trips, and the client may send its request as the SYN-ACK arrives."
+	},
+	syn: {
+		id: "syn",
+		label: "The SYN is lost",
+		noticedBy: "the client, after a timeout",
+		note: "The server never knew a connection was attempted. Only the client can notice, and it has nothing to go on but a clock."
+	},
+	"syn-ack": {
+		id: "syn-ack",
+		label: "The SYN-ACK is lost",
+		noticedBy: "the client, after a timeout",
+		note: "The server is now holding a half-open connection it thinks is progressing. The client sees only silence and retries its SYN."
+	},
+	ack: {
+		id: "ack",
+		label: "The final ACK is lost",
+		noticedBy: "the server, after a timeout",
+		note: "The client already believes it is connected and may start sending. The server does not, and re-sends its SYN-ACK until it hears something."
+	}
+};
+
+//#endregion
+export { DEFAULT_RTO_MS, DROPS, firstResponseMs, handshake };