From f3b7edbd1105ddbdef72d783d2b89c84b88f1017 Mon Sep 17 00:00:00 2001 From: Cameron Gutman Date: Tue, 4 Jul 2023 16:51:35 -0500 Subject: [PATCH] Overflow onto channel 0 rather than distributing This allows the host to make some assumptions about channel IDs --- src/ControlStream.c | 13 +++---------- 1 file changed, 3 insertions(+), 10 deletions(-) diff --git a/src/ControlStream.c b/src/ControlStream.c index b5b4334..7ef68b0 100644 --- a/src/ControlStream.c +++ b/src/ControlStream.c @@ -630,18 +630,11 @@ static bool sendMessageEnet(short ptype, short paylen, const void* payload, uint enetPacket->userData = (void*)&packetFreed; enetPacket->freeCallback = enetPacketFreeCb; - // channelCount == 0 is possible if the peer is disconnected, - // so we need to assign channel ID under the enetMutex to prevent - // racing updates the peer. - if (!IS_SUNSHINE() || peer->channelCount == 0) { - // We always use a single channel for GFE. + // Always use channel 0 for GFE and if the requested channel exceeds + // the peer's supported channel count. + if (!IS_SUNSHINE() || channelId >= peer->channelCount) { channelId = 0; } - else if (channelId >= peer->channelCount) { - // If this peer doesn't support enough channels, distribute the remaining channels onto the ones - // the peer does support. We don't use the channel to distinguish traffic types, so this is safe. - channelId %= peer->channelCount; - } // Queue the packet to be sent err = enet_peer_send(peer, channelId, enetPacket);