From owner-freebsd-hackers Thu Feb 20 09:57:39 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id JAA26493 for hackers-outgoing; Thu, 20 Feb 1997 09:57:39 -0800 (PST) Received: from who.cdrom.com (who.cdrom.com [204.216.27.3]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id JAA26458 for ; Thu, 20 Feb 1997 09:57:34 -0800 (PST) Received: from scanner.worldgate.com (scanner.worldgate.com [198.161.84.3]) by who.cdrom.com (8.7.5/8.6.11) with ESMTP id JAA24524 for ; Thu, 20 Feb 1997 09:52:48 -0800 (PST) Received: from znep.com (uucp@localhost) by scanner.worldgate.com (8.8.5/8.7.3) with UUCP id KAA04400; Thu, 20 Feb 1997 10:51:20 -0700 (MST) Received: from localhost (marcs@localhost) by alive.znep.com (8.7.5/8.7.3) with SMTP id KAA08664; Thu, 20 Feb 1997 10:48:38 -0700 (MST) Date: Thu, 20 Feb 1997 10:48:37 -0700 (MST) From: Marc Slemko To: David Nugent cc: freebsd-hackers@FreeBSD.ORG Subject: Re: "connection refused" In-Reply-To: <19970221004812.00805@usn.blaze.net.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Fri, 21 Feb 1997, David Nugent wrote: > On Feb 02, 1997 at 12:36:59AM, Darren Reed wrote: > > > One can obtain user connection request data without confirming the con- > > > nection by issuing a recvmsg(2) call with an msg_iovlen of 0 and a non- > > > zero msg_controllen, or by issuing a getsockopt(2) request. Similarly, > > > one can provide user connection rejection information by issuing a > > > sendmsg(2) call with providing only the control information, or by call- > > > ing setsockopt(2). > > > > > > Unless I'm reading this incorrectly, this is precisely what I'd like > > > to do. I just can work out how to do it. :-) See the paragraph before thst: For certain protocols which require an explicit confirmation, such as ISO or DATAKIT, accept() can be thought of as merely dequeueing the next connection request and not implying confirmation. Confirmation can be implied by a normal read or write on the new file descriptor, and rejection can be implied by closing the new socket. I think this was an addition to 4.4BSD (for ISO stuff?) and TCP doesn't use it. > > What does it say before that ? A connection is ESTABLISHED before it > > comes back via accept(). > > Ok. Then recvmsg() should be used without (instead of) accept()? A connection is established before you call accept() (or before it unblocks, if you called it earlier). When you call listen() all the connection establishment is done; anything you could setup would need to be done before listen(), since after that the normal processing automatically competes the three-way TCP handshake before it is made available to accept().