From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ffbox0-bg.mplayerhq.hu (ffbox0-bg.ffmpeg.org [79.124.17.100]) by master.gitmailbox.com (Postfix) with ESMTP id 28572448BA for ; Tue, 3 Jan 2023 09:03:44 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 85F3B68B9FA; Tue, 3 Jan 2023 11:03:40 +0200 (EET) Received: from mail-wm1-f52.google.com (mail-wm1-f52.google.com [209.85.128.52]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 6629468B9FA for ; Tue, 3 Jan 2023 11:03:33 +0200 (EET) Received: by mail-wm1-f52.google.com with SMTP id k22-20020a05600c1c9600b003d1ee3a6289so22576996wms.2 for ; Tue, 03 Jan 2023 01:03:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=voila.events; s=google; h=content-transfer-encoding:mime-version:user-agent:references :in-reply-to:date:to:from:subject:message-id:from:to:cc:subject:date :message-id:reply-to; bh=m0qYIzElkPnPYtO+5IPeU/gX6eSVR6ET1GJS/TRT5DI=; b=gYM3wQyaOOHDqhLYUfuscegP+YLeMkyIfJmKrzE9Xl6fQC2tLShA8mI4i6jEf6Z+0w qhijNwU03gEH+4zKdHtHfum0RlgDFwx5d4kgyiT+mOOCrbEqt1SA81TqPRN3Q3meg/3A jeAGQGT23Gef2oeNWlCL29a31fm6ja1W98a2o= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:user-agent:references :in-reply-to:date:to:from:subject:message-id:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=m0qYIzElkPnPYtO+5IPeU/gX6eSVR6ET1GJS/TRT5DI=; b=MRS+3gtXq9ZxdHfYbEid1wyqFq8cbONSo6JXV1Q09EY9VMi6AvEcxEOBUqCMMfmSDC D5ETbh58nvgs6Q5kfLA3sZBbrLHW5N6+dejllLc3fPFtfPY59vXTevQNPH3M1rk9V6Xj AzVaQHtYwxbQDtiYwVUDwOtX6rknwhn48Jg4dr3FrZOntmhZIY33SuyOV49xZTv84Eb4 rSW2mvboh9lywy7MZ6JJzpqvnFanxf8ojDlpGlzgDZjkaXHJtRTQdk4xyQTA428z6vZr itt+yq0rTZ31RTl2m9yk3VniR6GrrTglncjTS9YYRaNDLuBZW0LHFpH1sFqdiZwl98JV JffQ== X-Gm-Message-State: AFqh2krztIWW7K7P58XkLeRki9cbGFwOug77GFFnEMQKrFJVn+Ig2QD1 1NltbQrkUho3dfUuN3n9/e+7YM5qtETpao4I63Y= X-Google-Smtp-Source: AMrXdXswJwWkkREkKgtrS5SjP/YvY91rmpdd462fiBf7CF4yg76aKIbgXhFWB0bNPhyFJczHN4Q5bQ== X-Received: by 2002:a05:600c:4e90:b0:3cf:894f:964b with SMTP id f16-20020a05600c4e9000b003cf894f964bmr31635541wmq.16.1672736612022; Tue, 03 Jan 2023 01:03:32 -0800 (PST) Received: from colap3.home (lfbn-ren-1-691-195.w81-53.abo.wanadoo.fr. [81.53.29.195]) by smtp.gmail.com with ESMTPSA id n64-20020a1ca443000000b003d21759db42sm46180190wme.5.2023.01.03.01.03.30 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 03 Jan 2023 01:03:31 -0800 (PST) Message-ID: <61a2d014dae2970ffa0a68097b26eec8cac9a399.camel@voila.events> From: Camille Oudot To: ffmpeg-devel@ffmpeg.org Date: Tue, 03 Jan 2023 10:03:30 +0100 In-Reply-To: <12120876.O9o76ZdvQC@basile.remlab.net> References: <12120876.O9o76ZdvQC@basile.remlab.net> User-Agent: Evolution 3.38.3-1+deb11u1 MIME-Version: 1.0 Subject: Re: [FFmpeg-devel] [PATCH] avformat/rtpproto: add support for RTP/UDP socket reuse X-BeenThere: ffmpeg-devel@ffmpeg.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: FFmpeg development discussions and patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: FFmpeg development discussions and patches Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: 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-request@ffmpeg.org with subject "unsubscribe".