From owner-freebsd-net@FreeBSD.ORG Mon Dec 1 15:26:42 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 D7FD947E for ; Mon, 1 Dec 2014 15:26:42 +0000 (UTC) Received: from shell1.rawbw.com (shell1.rawbw.com [198.144.192.42]) by mx1.freebsd.org (Postfix) with ESMTP id C1A23CC9 for ; Mon, 1 Dec 2014 15:26:42 +0000 (UTC) Received: from eagle.yuri.org (c-73-162-232-245.hsd1.ca.comcast.net [73.162.232.245]) (authenticated bits=0) by shell1.rawbw.com (8.14.9/8.14.9) with ESMTP id sB1FQccJ092547 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 1 Dec 2014 07:26:39 -0800 (PST) (envelope-from yuri@rawbw.com) X-Authentication-Warning: shell1.rawbw.com: Host c-73-162-232-245.hsd1.ca.comcast.net [73.162.232.245] claimed to be eagle.yuri.org Message-ID: <547C88AD.40407@rawbw.com> Date: Mon, 01 Dec 2014 07:26:37 -0800 From: Yuri User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Daniel Corbe Subject: Re: Can multiple apps listen for TCP on the same port? References: <547C5DD3.90604@rawbw.com> <20141201150225.GB64370@apollo.corbe.net> In-Reply-To: <20141201150225.GB64370@apollo.corbe.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org 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 15:26:42 -0000 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