Study UDP Ping Mechanism

[Yundi339]

Select Topic Area

Question

Body

I recently reviewed the UDP connection and ping-handling logic in both Sunshine and Moonlight, mainly focusing on stream.cpp.
In Sunshine, when establishing a connection, if the server does not receive the expected UDP ping payload or "PING" packet, it logs:

Error: Initial Ping Timeout

This seems to be a core part of the UDP handshake sequence between Sunshine and Moonlight.

Problem Description

I've observed (and Remote Debugging) several user computers where this issue occurred.
And all environments were tested Windows 11.

---

Case A — IPv6 behavior inconsistent between Internet and LAN

• This issue occurred after a Windows system fault caused by low disk space, which may have affected Winsock or UDP socket state. So I think it can be solved by reinstalling the system
• When connected over IPV4&IPv6 within the local LAN, streaming works normally.
• However, when connecting through IPv6 over the Internet, the connection fails, and Sunshine logs Error: Initial Ping Timeout.
• Interestingly, the same system connects fine using IPv4 over the Internet.

---

Case B — Quest 3's moonlight fails while phone's moonlight works (same LAN)

• Pure LAN setup (no Internet).
• The Android Moonlight works fine and can stream normally.
• The Quest 3 Moonlight fails to communicate with Sunshine, log displayed "Error: Initial Ping Timeout".
• However, when the Quest 3 connects through PC hotspot, streaming works perfectly.
• I initially suspected the router, it's old still use WIFI5, but even after buy a new WIFI6 router, the issue persists.

---

Related Discussion

I’ve read other discussion mentioning that the current UDP ping mechanism might also cause reconnection failures after a stream interruption.
From the symptoms, I suspect these might share the same underlying root cause — something related to the UDP ping lifecycle .

LizardByte/Sunshine#4168
https://github.com/orgs/LizardByte/discussions/182

Main Question

I want to clarify whether Moonlight uses any special logic when initiating communication on UDP port 47999 compared to 48000.
From logs, both Sunshine and Moonlight can communicate normally over 48000, but 47999 fails to work.

---

Proposal

Would it be feasible to introduce a dedicated UDP port to handle the PING mechanism separately from the main video/audio/control channels?

The rationale:

• Isolate potential handshake or keepalive issues from data channel traffic.
• Simplify debugging and tracing of UDP handshake failures.
• Reduce reconnect failures caused by socket reuse or unclean teardown.

I also tested the same environments using iperf for UDP upload/download speed tests.
All UDP traffic tests ran successfully with no packet loss or timeout.
This indicates that the network stack and UDP routing are functional — suggesting the issue is specific to Sunshine’s UDP Ping mechanism or its initial handshake logic rather than a general UDP connectivity problem.

Because of this, I’m planning to develop and experiment with a refined UDP PING handshake mechanism, to test whether improving the sequence or timeout behavior could increase reliability.