# Request #3: the forked NGO batch/message framing and ConnectionApproved

The LiteNetLib layer is solved and the client now completes the transport handshake against
our server and sends its NGO ConnectionRequest. We decoded it and confirmed the Tachyon JSON
(`AI/AT/VB/CKA/CIA/CPK`). But the fork changed NGO's batch and message framing, so we cannot
send a ConnectionApproved the client will accept without the exact serialization.

## What we already worked out from the wire (for your cross-check)

Decoded from a real 2041-byte ConnectionRequest batch:

```
[0:2]    magic  u16 = 0x1160
[2:4]    count  u16 = 0                     (stock BatchCount, sent as 0)
[4:8]    size   u32 = 2041                  (total datagram length)
[8:16]   hash   u64 = 0x3faa53cee8c5e338    (= XXHash64 over bytes [24:2041], VERIFIED)
[16:24]  u64        = 1                      (fork field; equals message count here)
[24]     bitpacked  = 1                      (message type: ConnectionRequest, client-local idx)
[25:27]  bitpacked  = 2014                   (message size)
[27]     0x81                                (version-header preamble byte)
[28:63]  7 × { u32 hash ; 1 byte version=0 }
[63:68]  00 00 00 00 01                      (5 bytes, not in stock NGO)
[68:76]  u64 ConfigHash
[76:80]  u32 = 1961  (ConnData length)
[80:2041] Tachyon JSON
```

So the batch hash covers `[24:end]` (message stream), NOT stock's `[16:alignedLength]`, and
the batch is NOT padded to 8 bytes. Two message-body bytes are unexplained: the `0x81`
preamble, and the `00 00 00 00 01`.

## Questions (in priority order)

**Q1 — forked batch header & hash, in `NetworkMessageManager`.**
Confirm the header layout above. Specifically:
- Is the `u64` at `[16:24]` the message count, a tick, or something else? What writes it?
- Confirm `BatchHash = XXHash64(buffer + 24, size - 24)` (or give the real range/seed).
- **Does the RECEIVER validate `BatchHash` and reject on mismatch, or log-and-continue?**
  This decides whether our outbound hash must be exact.
- Does the receiver iterate messages by the `u64` count, by `BatchCount`, or by position?

**Q2 — the version-header preamble.**
In the forked `ConnectionRequestMessage.Serialize` (and the shared version-header code), what
is written before the version table? Stock writes `BytePacker.WriteValueBitPacked(N)` (N=7 ->
`0x39`). We see a single `0x81`. And what is the `00 00 00 00 01` written AFTER the table,
before `ConfigHash`? Give the exact field sequence of the forbidden segment as this build
serializes it.

**Q3 — `ConnectionApprovedMessage` serialization (the thing we must send).**
Full `Serialize` (server→client) for this build. We need every field and its encoding, in
order: the version header (same preamble as Q2?), `OwnerClientId`, `NetworkTick`, any
`ConnectedClientIds`, `sceneObjectCount`, and anything the fork added. Also the message
**type index** the client expects for ConnectionApproved in the pre-approval (local) space,
and how `Deserialize` reads it — because the client's `Deserialize` is what accepts or rejects
our packet.

**Q4 — how the approval reaches Tachyon.**
Earlier finding: `NetworkManager.RecRoom_ConnectionInfo` is a fork addition, hypothesised to
carry the approval JSON (`PMFAAFNFMAL`, the `"Carrot"` / `SessionKeyB` blob). Confirm whether
the approval JSON rides inside `ConnectionApprovedMessage`'s ConnectionData, in
`RecRoom_ConnectionInfo`, or elsewhere — i.e. where in the server→client bytes we must place
`{"DR":"Carrot",...}`.

**Q5 — key-null path for the session.**
Does the client require a non-null `SessionKeyB` to proceed, or will it accept an approval with
`"Carrot"` and no key and stay plaintext (marker `0x11`)? This decides whether we can defer the
RSA keypair patch and run voice unencrypted.

## Output

Decompiled `Serialize`/`Deserialize` bodies where possible, else exact field order + encodings
+ byte offsets. Distinguish read from inferred. If a field genuinely is not present, say so —
do not fill it from stock NGO; the fork has already diverged in three places above.