-
Notifications
You must be signed in to change notification settings - Fork 49
Description
Reactor currently enforces that the mod handshake packet must be the very first reliable message sent during the connection. If any other message (from either the server or the client) is sent before the Reactor handshake, the client treats this as an error and forcibly disconnects.
This behavior is hard-coded in the client and makes Reactor assume exclusive control over the initial packet order, which creates compatibility and extensibility issues.
Relevant Code
The issue originates from the logic in InnerNetClient.HandleMessage:
if (ReactorConnection.Instance!.Syncer == null)
{
var parentBuffer = reader.Parent.Buffer;
var sendOption = (SendOption) parentBuffer[0];
if (sendOption == SendOption.Reliable)
{
var id = (ushort) ((parentBuffer[1] << 8) + parentBuffer[2]);
isFirst = id == 1;
}
}If a Reactor handshake (ReactorMessageFlags.Handshake) is received and isFirst is false, the client immediately disconnects:
Warning("Modded handshake came in late");
__instance.DisconnectWithReason(
"Reactor handshake was sent out of order, please try connecting again."
);Additionally, if the first reliable packet is not a Reactor handshake, the client assumes the server is unmodded and switches to HAAS mode:
if (isFirst)
{
ReactorConnection.Instance.Syncer = Syncer.Host;
Warning("Server is not modded, falling back to HAAS");
}Expected Behavior
- The server should be allowed to send messages before the Reactor handshake.
- Client mods should also be able to send messages before or alongside the handshake.
- The handshake should be validated logically (e.g. once per connection), not strictly by packet order.
Actual Behavior
-
Reactor requires its handshake to be the very first reliable packet.
-
Any earlier packet causes the client to:
- Misidentify the server as unmodded, or
- Forcefully disconnect if the handshake arrives later.
-
This effectively gives Reactor exclusive ownership of the first packet in the connection.
Impact
- Breaks compatibility with other mods or middleware that need to send early connection messages.
- Prevents servers from performing legitimate initialization or negotiation before Reactor’s handshake.
- Makes the networking layer fragile and overly order-dependent.
- Hard-codes Reactor as the only component allowed to send the first reliable packet.
Suggested Fix / Improvement
- Do not require the Reactor handshake to be the first reliable packet.
- Allow the handshake to arrive at any point before gameplay-critical synchronization begins.
- Replace packet-order checks with explicit state validation (e.g. “handshake not yet processed”).
- Avoid forced disconnects purely due to message ordering.
Additional Notes
Reactor.Impostor is designed to always send a reliable handshake first, but this constraint should not be enforced globally by the client. The current implementation limits extensibility and introduces unnecessary disconnects.