Date: Sat, 8 Sep 2001 17:51:13 +0300 From: "Vladimir A. Jakovenko" <vovik@lucky.net> To: Terry Lambert <tlambert2@mindspring.com> Cc: freebsd-net@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: SO_REUSEPORT on unicast UDP sockets Message-ID: <20010908175113.B84471@lucky.net> In-Reply-To: <3B991962.C8D0A398@mindspring.com>; from tlambert2@mindspring.com on Fri, Sep 07, 2001 at 12:00:50PM -0700 References: <20010902054617.A47742@lucky.net> <3B947922.F8B98DBD@mindspring.com> <20010907134403.T2693@lucky.net> <3B991962.C8D0A398@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Sep 07, 2001 at 12:00:50PM -0700, Terry Lambert wrote: >"Vladimir A. Jakovenko" wrote: >> Terry, I clearly understand all your explanations. Yes, we are living in >> real life and there is a lot of programms with bad design. >> >> But all what I want is possibility to receive UDP packets with >> corresponding dst IP and port by more than one process on a single >> host. This already works for Broadcast and Multicast addresses. If >> I want to get same functionality for unicast (without any kernel >> changes) I have to use UDP-proxy, which redirects given datagrams >> to loopback broadcast address, where they can be received by more >> that one process. > >Yes. Ok. >> According to comment in udp_input() SO_REUSEPORT hack on unicast >> sockets could be used in single process, right? > >Yes. Ok. >> How possibility to get duplicate traffic on two UDP sockets, which >> was created in _different_ processes with the same local address >> and port values, would break existing applications? >Consider a UDP based reliable delivery protocol that cares >about key frames, but not about all frames. A good example >of this would be any RTSP/RTP type protocol implemented on >UDP, which was used to implement streaming video of a live >broadcast, using limited buffer space. Terry, your example is right for UDP services which requires _acknowledgment_. But in my case what I need is the simple, even classic, unreliable UDP datastream delivery _without_ acknowledgment_ destinated to one or _more_ processes on single host. Yes, multicast (and even broadcast) is good, but not all time. I.e. if in one broadcast domain exists at least one non trusted host it would be difficult (and in the case of broadcast not possible) to restrict such host ability to receive traffic destinated to multicast group if other hosts should have ability to join group and receive traffic. Lets sum up all mentioned issues: 1. There is restriction in FreeBSD kernel about processing SO_REUSEPORT socket option on UDP scokets, which allows more than one binding to given ip:port on one host. This restriction blocks possibility to obtain UNICAST traffic destinated to same ip:port by two or more processes simultaneously. 2. If this restriction would be removed only for sockets crated by different processes it would not break existing applications. Am I right? -- Regards, Vladimir. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010908175113.B84471>