forked from unom/punktfunk
enricobuehler
e44f2b1024
Disconnecting the ENet peer stopped the freeze but the client then reported the session as error -1: a bare disconnect is indistinguishable from the host falling over, so Moonlight called it a connection failure. Which, from its side, was a fair reading — we never said otherwise. The protocol has a word for this. Send the TERMINATION control message with `NVST_DISCONN_SERVER_TERMINATED_CLOSED` first, then disconnect; the client maps that to a graceful termination (given it has seen a frame, true of any real session) and lands the player back in the app list. Constants verified against moonlight-common-c `ControlStream.c` rather than recalled, because every way of getting this wrong is silent — the client ignores an unparseable control message, which reads on glass as the same freeze: * the type comes from the table the CLIENT chose, so it is derived from the negotiated nonce scheme (plain 0x0100 / encrypted 0x0109) instead of guessed, * the reason is BIG-endian (the >=6-byte branch; the short branch is a little-endian u16, which is GFE's older shape). `disconnect_later` rather than `disconnect`, so the queued message actually reaches the wire instead of racing the teardown — which would land us back at -1. The session's GCM key is cached per tick because ending a session clears the launch state the key lives in, and this is precisely the message that has to be sealed after that.