chore(rendezvous): drop unsupported UDP PunchHoleRequest and LocalAddr handlers - #35
Merged
Merged
Conversation
…r handlers The client never sends PunchHoleRequest or LocalAddr over UDP: - PunchHoleRequest is sent over TCP/WS (client.rs _start_inner uses connect_tcp) - LocalAddr is sent over TCP (rendezvous_mediator.rs handle_intranet_ uses connect_tcp) Remove the dead UDP handlers in handle_udp and delete the now-unused handle_udp_punch_hole_request function. Keep UDP PunchHoleSent handling because the client does send it over UDP when ph.udp_port > 0.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Remove UDP handlers in
handle_udpforPunchHoleRequestandLocalAddrmessages that the client never sends over UDP, and delete the now-deadhandle_udp_punch_hole_requestfunction.Analysis
Independent code trace of the upstream client (
rustdesk/rustdesk) confirms the actual transport channel for each rendezvous message:PunchHoleRequestclient.rs:482(_start_inner)connect_tcpatclient.rs:394)PunchHoleSentrendezvous_mediator.rs:735(punch_udp_hole)ph.udp_port > 0(new_direct_udp_for)LocalAddrrendezvous_mediator.rs:645(handle_intranet_)connect_tcpatrendezvous_mediator.rs:629)The client always opens a TCP connection to the rendezvous server in
_start_innerand sendsPunchHoleRequestover that TCP socket.LocalAddris likewise sent over a TCP connection inhandle_intranet_. OnlyPunchHoleSentis genuinely sent over UDP (viapunch_udp_holewhen the peer'sudp_port > 0).Changes
handle_udp: replacePunchHoleRequestandLocalAddrarms with intentionally-unsupported no-ops (matching upstream's approach)handle_udp_punch_hole_request(was only called from the removedPunchHoleRequestarm)PunchHoleSentUDP handling unchanged — the client relies on it for UDP/KCP direct connectionsNote
This aligns the server with what the client actually does over UDP, while preserving the
PunchHoleSentUDP path that PR #32 intentionally kept (excluded from the upstream UDP punch-hole disabling).