Fragmentation

A WebSocket message and a WebSocket frame are not the same thing. A sender may split one logical message across many frames — because it's streaming data whose total size it doesn't know yet, because it wants bounded buffers, or because it wants to squeeze a PING in mid-transfer instead of stalling behind 100MB of upload.

The anatomy of a fragmented message

Two header fields drive everything: FIN (is this the last frame of the message?) and opcode.

FIN=0 opcode=TEXT          "Hello "
FIN=0 opcode=CONTINUATION  "World "
FIN=1 opcode=CONTINUATION  "!"
        -> one TEXT message: "Hello World !"

Only the first fragment names the type. The receiver must remember it — when the message completes, it reports the initial opcode, not CONTINUATION.

The receiver's state machine is small: keep a per-connection accumulator (initial_opcode, buffer). Data frame with FIN=1 and no accumulator → complete message immediately. Data frame with FIN=0 → start accumulating. CONTINUATION → append; if FIN=1, emit the assembled message and clear.

Control frames cut in line

PING, PONG, and CLOSE (opcodes 0x8–0xA) may appear between fragments of a data message — that's half the reason fragmentation exists. But control frames themselves are never fragmented: they must have FIN=1 and a payload of at most 125 bytes (RFC 6455 §5.5), so a receiver can always process one instantly without its own reassembly buffer. Crucially, an interleaved PING must not disturb your accumulator — handle it, then continue appending fragments as if nothing happened.

The violations you must catch

RFC 6455 says a receiver must fail the connection on malformed fragment sequences. Your reassembler detects three:

• ERR continuation-without-start — a CONTINUATION arrives with no message in progress. There is nothing to continue.
• ERR new-data-mid-fragment — a fresh TEXT/BINARY arrives while a message is still being assembled. Only one data message per direction can be in flight at a time.
• ERR control-not-fin — a control frame with FIN=0.

Your exercise

Implement the reassembler. The trap that fails most submissions is the mid-fragment error: for

FRAME 0 TEXT 48
FRAME 1 TEXT 49

the grader expects exactly one line, ERR new-data-mid-fragment. The offending frame is discarded and the accumulator reset — if you reset and then also process 49 as a fresh message, you'll print a second line MSG opcode=TEXT payload=49 and fail. Two more exact-output details: a completed fragmented BINARY must report the initial opcode — MSG opcode=BINARY payload=001122, never opcode=CONTINUATION — and an empty single-frame TEXT still prints MSG opcode=TEXT payload= with nothing after the =.