Hi, I'm back on the topic. Thanks to all of you for your comments. > So I agree that SO_REUSEADDR is "absolutely not a hack"... if you use > it to recycle IP/port pair without waiting for the time-out. But > that's mainly of interest of listening/receiving sockets.
That is indeed the case for TCP sockets, but as far as I know this does not apply to UDP as there is no TIME_WAIT state associated to datagram sockets. The classical use of this option would be for having a process binding on udp:0.0.0.0:1234 then another one binding on e.g. udp:192.168.1.10:1234 without triggering a "address in use" error. This is indeed a matter of listening socket. > If you use it to bind two concurrent sockets on the same IP/port > pair, then it is absolutely not just a hack but a platform-dependent > non-portable hack and a latent vulnerability in the OS (since one > process can hijack datagrams for another). The use of REUSEPORT instead of REUSEADDR is meant to mitigate this risk (but it's far from perfect). I definitely agree that using these options instead of refactoring or rewriting the RTP protocol to support RTP bundle and RTCP mux is a hack. I should take some time in the future to look into a proper solution. In the meantime, several people are looking for this feature: - http://ffmpeg.org/pipermail/ffmpeg-user/2018-September/041393.html - https://trac.ffmpeg.org/ticket/1774 - https://mediasoup.discourse.group/t/simulcast-with-plainrtptransport-and-ffmpeg/863 When the REUSEADDR option was added in FFmpeg UDP protocol what was the reason back then? And wouldn't this reason also apply for RTP? If we enable it for some legit reason, this could provide a (hacky and OS- dependent) solution for RTP bundle and RTCP mux, until the RTP protocol is properly refactored. Regards -- Camille _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".