[richard-ramos]

Summary

Preserve the concrete local address when QUIC uses a wildcard-bound UDP socket
on Linux:

• pass each datagram destination address into LSQUIC
• select that source address on outbound packets with packet-info ancillary data
• initialize outgoing connections with the route-selected local address

This keeps LSQUIC path identity stable while allowing one dual-stack listener
socket to dial IPv4 peers.

Dependency

• Draft: feat(datagram): expose received destination address status-im/nim-chronos#743

Impact on Library Users

Linux endpoints can use wildcard listener sockets for outbound QUIC without
losing source-address control. Non-Linux behavior is unchanged.

Risk Assessment

The change affects Linux QUIC packet I/O. It retains the existing sendmmsg
batching and caps receive draining as before.

References

• https://blog.cloudflare.com/everything-you-ever-wanted-to-know-about-udp-sockets-but-were-afraid-to-ask-part-1/#sourcing-packets-from-a-wildcard-socket

[richard-ramos]

/review pro

[richard-ramos]

/review pro

[github-actions]

🔍 OpenCodeReview found 5 issue(s) in this PR.

• ✅ Successfully posted inline: 5 comment(s)

[gmelodie]

1. I think it should be possible to use only one definition of ControlBuffer for all systems, no?
2. Instead of having huge portions of the code inside when blocks, we could have these blocks inside procs e.g. instead of two definitions of prepareSourceAddr we could have:

proc prepareSourceAddr() = 
  when defined(linux):
    prepareSourceAddrPosix
  when defined(windows):
    prepareSourceAddrWin

obs: also address cmsg logic which is duplicated in both definitions of prepareSourceAddr

4. Tests do not seem to cover windows + WSASendMsg, IPv6 pktinfo send or macOS.

5. I see recvFrom was dropped from windows and mac, but that means a perf drawback for UDP on these platforms. Can we not implement them for windows (leveraging WSARecvMsg) and mac (using IP_RECVPKTINFO and IPV6_RECVPKTINFO)?