mirror of
https://code.videolan.org/rist/librist.git
synced 2026-07-04 15:06:53 +00:00
Sergio Ammirata
0cf88d505a
udpsocket_set_optimal_buffer_size()/_send_size() requested a fixed 1 MB
SO_RCVBUF/SO_SNDBUF and, on failure, fell back to ~200 KB. They never used
the headroom a large net.core.{r,w}mem_max provides. That headroom is what
lets a listener absorb a burst of simultaneous connections: a single
protocol thread drains one UDP socket, so when many peers establish at once
the inbound control/handshake traffic can momentarily exceed 1 MB and the
kernel silently drops the overflow, stalling the peers whose handshake
packets were lost.
Measured on a 16-core x86 listener (net.core.rmem_max = 16 MB) with 200
peers dialing in within <1 s: at the 1 MB buffer the kernel dropped 924
datagrams at the socket (Udp: RcvbufErrors) and only ~158/200 peers
completed authentication; the protocol thread sat at 9% of one core the
whole time, so it was never the bottleneck. Rebuilt with the buffer sized
to the OS maximum, the same storm dropped 0 datagrams and all peers
connected (256/256 at the 256-flow cap).
Request UDPSOCKET_SOCK_BUFSIZE_MAX (8 MB) and let the kernel clamp to
*mem_max, keeping whatever we obtain as long as it is at least the historical
1 MB floor; otherwise fall back to the ~200 KB last resort and warning
exactly as before. No API/ABI change, no new configuration, and hosts with a
small *mem_max are unaffected (they still settle at the same fallback). Also
correct the send-buffer error message to reference wmem_max instead of
rmem_max.