From owner-freebsd-net@FreeBSD.ORG Mon Dec 1 17:12:36 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C108F854 for ; Mon, 1 Dec 2014 17:12:36 +0000 (UTC) Received: from mail.as41113.net (mail.as41113.net [91.208.177.22]) by mx1.freebsd.org (Postfix) with ESMTP id 83067B50 for ; Mon, 1 Dec 2014 17:12:36 +0000 (UTC) Received: from [172.21.87.41] (193.98.9.212.in-addr.arpa [212.9.98.193]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: lists@rewt.org.uk) by mail.as41113.net (Postfix) with ESMTPSA id 3jrt7w3wYLz1N2P7 for ; Mon, 1 Dec 2014 17:03:56 +0000 (GMT) Message-ID: <547C9F7A.5000803@rewt.org.uk> Date: Mon, 01 Dec 2014 17:03:54 +0000 From: Joe Holden User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Re: Can multiple apps listen for TCP on the same port? References: <547C5DD3.90604@rawbw.com> <20141201150225.GB64370@apollo.corbe.net> <547C88AD.40407@rawbw.com> <20141201153712.4304976.24709.1746@denninger.net> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Dec 2014 17:12:36 -0000 Was there a specific reason why we couldn't just extend REUSEADDR/PORT to do this a la Linux? Just a simple round robin would make those useful perhaps On 01/12/2014 16:21, Adrian Chadd wrote: > Hi, > > I introduced a socket option in -HEAD that lets you bind multiple > things to the same listen ports. > > They're only load balanced if you're using RSS and set up RSS socket > options as well; otherwise only one gets the incoming requests. > > IP_BINDMULTI and IP6_BINDMULTI. > > > -a > > > On 1 December 2014 at 08:14, Someone Somewhere > wrote: >> @Yuri , are you sure that the second instance of nc does not accept any >> connection? >> I did a simple test : -> >> #: nc -l 12345 (shell 1) >> #: nc localhost 12345 (shell2) >> at this point netstat shows that there is no one listening on 12345. This >> means any process should not be able to bind over port 12345(over TCP). >> # nc -l 12345 (shell 3, shell 1 , 2 still active) >> this instance of nc starts listening which I could verify via netstat cmd. >> # nc localhost 12345 (shell 4) >> this nc instance connected to the nc started in previous step over shell 3. >> >> Test ran on Fedora 20. >> [will try this on freeBSD VM if you confirm that this is what you are >> trying] >> >> >> Could you verify if your second nc(server) instance is listening on the >> same socket number? >> >> >> -Kunal. >> >> >> >> On 1 December 2014 at 21:07, Karl Denninger wrote: >> >>> The second bind() call does fail but if the application ignores the return >>> code...‎. Are you sure all the associated system call return codes are >>> being checked? >>> >>> The right way to do this Imho is to have a parent process that calls bind >>> and listen, gets the notification of an incoming connection via select() >>> (allowing detection of exceptions as well) and then calls accept() and, now >>> having a connected file handle, fork()s and executes whatever is to handle >>> the connection with the parent closing the handle so as to not orphan the >>> handle when the child exits. >>> ‎ >>> -- Karl >>> (On Passport PDA)‎ >>> >>> >>> Original Message >>> From: Yuri‎ >>> Sent: Monday, December 1, 2014 10:26 >>> To: Daniel Corbe >>> Cc: freebsd-net@freebsd.org >>> Subject: Re: Can multiple apps listen for TCP on the same port? >>> >>> On 12/01/2014 07:02, Daniel Corbe wrote: >>>> Generally the answer to your question is no. Two applications cannot >>>> occupy the same port on the same protocol at the same time. >>>> >>>> To expand on this answer and to hopefully shed some light on why the >>>> behavior you're observing with your application is absolutely correct; >>>> the calling application (in this case, nc) has to explicitly call bind(2) >>>> before it can begin accepting connections. If that port is already in >>>> use then the call to bind(2) will fail. And in your case I suspect nc >>>> is simply choosing to silently fail. >>> >>> Here the question is what does it mean "occupy the port"? The first >>> instance isn't listening any more. The listening socket was closed. Why >>> the presence of the socket that was accepted from (now closed) listening >>> socket in the first instance is considered "occupying it"? >>> >>> Actually no system call in the second instance ever fails. >>> >>> Yuri >>> _______________________________________________ >>> freebsd-net@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-net >>> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >>> >>> >>> %SPAMBLOCK-SYS: Matched [@freebsd.org+], message ok >>> >>> >>> _______________________________________________ >>> freebsd-net@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-net >>> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >>> >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >