Date: Fri, 07 Sep 2001 12:00:50 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: "Vladimir A. Jakovenko" <vovik@lucky.net> Cc: freebsd-net@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: SO_REUSEPORT on unicast UDP sockets Message-ID: <3B991962.C8D0A398@mindspring.com> References: <20010902054617.A47742@lucky.net> <3B947922.F8B98DBD@mindspring.com> <20010907134403.T2693@lucky.net>
next in thread | previous in thread | raw e-mail | index | archive | help
"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. > According to comment in udp_input() SO_REUSEPORT hack on unicast > sockets could be used in single process, right? Yes. > 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. In this situation, the video is delivered by sending a key frame, and then subsequent data is sent as deltas on that key frame. Effectively, this MUXes two protocols: a reliable datagram protocol containing the key frames, and an unreliable protocol containing the deltas, over a single channel. This method of key frame use is the same method used to encode DVD data and a number of real time streaming protocols, including a number of streaming video protocols running over UDP (the original technique was pioneered by a company named CinemaWare, a Utah-based developer of Amiga software, which used a technique called "cell animation" to reduce image data size requirements). Your hypothetical two-process-no-proxy program would not correctly acknowledge key frames consisting of more than one UDP packet, unless you delivered the unicast to both. If you delivered the unicast to both, you would need to build an "acknowledgement proxy", which would only acknowledge when the entire key frame had been received by *both* processes. Taking an even simpler case, you could build a UDP packet payload classifier, which would classify UDP packets based on payload (size, etc.), and report statistics at the end of a run. Your change would result in erroneous reporting. On a philosophical note, it's questionable about whether a unicast is directed to an IP/port pair, or whether it is directed to a particular application, and the IP/port pair, or even the UDP protocol, are just a necessary vehicle for the delivery of the information. On a practical note, if you could fix the multiple delivery problem, so that only one listener got the packet, this would address many, but not all, of the objections above(*). On a purely technical note, I think you want to use something other than unicast for your implementation: multicast group seems to be the most correct fit (I am in the camp that a unicast is directed at an application, not merely a machine). (*) You would still have the problem of a meta relationship between multiple packets, and you would still have the problem of "correctly" selecting who would get the packet; right now, the behaviour is "first listener", not LRU more MRU... -- Terry 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?3B991962.C8D0A398>