From owner-freebsd-hackers Sat Sep 1 19:46:30 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from burka.carrier.kiev.ua (burka.carrier.kiev.ua [193.193.193.107]) by hub.freebsd.org (Postfix) with ESMTP id 6EFFD37B409; Sat, 1 Sep 2001 19:46:21 -0700 (PDT) Received: from vovik@localhost (vovik@localhost) by burka.carrier.kiev.ua id FRU49123; Sun, 2 Sep 2001 05:46:17 +0300 (EEST) (envelope-from vovik) Date: Sun, 2 Sep 2001 05:46:17 +0300 From: "Vladimir A. Jakovenko" To: freebsd-net@freebsd.org Cc: freebsd-hackers@freebsd.org Subject: SO_REUSEPORT on unicast UDP sockets Message-ID: <20010902054617.A47742@lucky.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hello! According to UNPv1 SO_REUSEPORT on UDP sockets can be used to bind more than one socket to the same port (even with same source ip address). But quick look on /sys/netinet/udp_usrreq.c function udp_input() shows that this will work as expected (data stream duplicate) only on multicast/broadcast local addresses. Please pay attention to the following code fragment comments: if (IN_MULTICAST(ntohl(ip->ip_dst.s_addr)) || in_broadcast(ip->ip_dst, m->m_pkthdr.rcvif)) { struct inpcb *last; /* * Deliver a multicast or broadcast datagram to *all* sockets * for which the local and remote addresses and ports match * those of the incoming datagram. This allows more than * one process to receive multi/broadcasts on the same port. * (This really ought to be done for unicast datagrams as * well, but that would cause problems with existing * applications that open both address-specific sockets and * a wildcard socket listening to the same port -- they would * end up receiving duplicates of every unicast datagram. * Those applications open the multiple sockets to overcome an * inadequacy of the UDP socket interface, but for backwards * compatibility we avoid the problem here rather than * fixing the interface. Maybe 4.5BSD will remedy this?) */ Is there still any real need in such backward compatibility? Can such functionality be added (fixed) with possibility to switch it off using sysctl or kernel-build option? I find such possibility realy useful at least for NetFlow data processing and believe that it would be useful for many UDP-based protocols. -- Regards, Vladimir. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message