# Request #5: exact Dissonance packet field encodings (client's PacketReader)

Request #4 landed it: NamedMessage = `u16 NamedMessageType LE` + `i32 length LE` + Dissonance
packet; reply on type 2 (DissonanceToClient); Dissonance is stock v8.x, magic `0x8bc7`
big-endian. We've implemented a best-effort HandshakeResponse from the docs' field lists and
are testing it live. This request is the authoritative fallback for the byte-exact encodings the
docs don't specify — read from the CLIENT's `PacketReader` (what parses what we send), which is
the ground truth for what we must produce.

Dissonance networking is in the un-indexed regions you noted; the reader methods are
`AJLLGKJMHIO` (PacketReader) / `BKJPKJLIHFE` @ 0x3136430 (magic check) and the `BaseClient`
handshake handler.

**Q1 — `ReadHandshakeResponse` exact layout.** After magic + type(5): confirm the order and
encoding of session id (u32?), assigned client id (u16?), and the three lists (clients, rooms,
listeners). For each list: is the count a **byte, u16, or u32** (big-endian?), and what is each
entry's layout? For the client list entry: name + codec settings + id — in what order, and how
is the **string (name)** encoded (length prefix width + UTF8? null sentinel?). Does the client
list include the joining client itself or only others?

**Q2 — `ReadClientState` layout.** Fields: name, client id, codec settings, rooms list. Same
questions — string encoding, list count width, field order. This is what we broadcast when a
second client joins so the two see each other.

**Q3 — `ReadVoiceData` header.** After magic+type(2)+session: sender client id (u16?), the
8-bit flags bitfield, the sequence number (u16?), and the "channels this voice is addressed to"
list (count width + per-channel layout). We want to relay the body verbatim — confirm the whole
packet after the session id can be forwarded unchanged to other clients, or if the server must
rewrite the sender id / channel list.

**Q4 — the `CodecSettings` block.** Confirm `byte codec, u32 frameSize, u32 sampleRate` (BE),
matching the captured HandshakeRequest (`01`, 960, 48000). Is there a trailing field? The
captured request had `00 02 32` after the codec settings that we read as the player name —
confirm the name encoding from `ReadHandshakeRequest`.

**Q5 — client id / session semantics.** Does the server pick the session id freely (any nonzero
u32)? What range/rule for assigned client ids (start value, reserved ids)? The client kicks on
"wrong session ID" for subsequent packets — confirm it stores the session from HandshakeResponse
and echoes it, so our chosen value just has to be consistent.

## Output

Byte offsets, field order, count widths, endianness, string encoding. This is the last layer —
once these are exact, plaintext voice relay is a direct implementation.