From owner-freebsd-questions Thu Feb 28 15:29:29 2002 Delivered-To: freebsd-questions@freebsd.org Received: from vulcan.rsasecurity.com (vulcan.rsasecurity.com [204.167.114.130]) by hub.freebsd.org (Postfix) with SMTP id 4F46737B41A for ; Thu, 28 Feb 2002 15:29:24 -0800 (PST) Received: from no.name.available by vulcan.rsasecurity.com via smtpd (for hub.FreeBSD.org [216.136.204.18]) with SMTP; 28 Feb 2002 23:29:05 UT Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id RAA17880 for ; Thu, 28 Feb 2002 17:03:16 -0500 (EST) Received: from spirit.dynas.se (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.9.1) with SMTP id g1SM3Pm16401 for ; Thu, 28 Feb 2002 17:03:25 -0500 (EST) Received: (qmail 15170 invoked from network); 28 Feb 2002 22:03:24 -0000 Received: from explorer.rsa.com (HELO mikko.rsa.com) (10.81.217.59) by spirit.dynas.se with SMTP; 28 Feb 2002 22:03:24 -0000 Date: Thu, 28 Feb 2002 14:03:20 -0800 (PST) From: =?ISO-8859-1?Q?Mikko_Ty=F6l=E4j=E4rvi?= X-X-Sender: mikko@mikko.rsa.com To: rfg@monkeys.com Cc: questions@freebsd.org Subject: Re: Annoying/non-intutive/undocumented poll(2) behavior: Bug or feature? Message-ID: <20020228140039.T93443-100000@mikko.rsa.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by sdtihq24.securid.com id RAA17880 Sender: owner-freebsd-questions@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG "Ronald F. Guilmette" : > Riddle: When is a socket error not a socket error? > > Answer: When you are using the poll(2) syscall in FreeBSD (4.3) to > check for the completion status of an outbound connect(2). > > I'm just about to file a formal problem on this, but I thought that I > would post it here first, in case anyone wants to talk me out of it, > or in case anyone wants to take issue with my analysis. > > Consider the simple example program below. It allocates a socket, sets > the O_NONBLOCK flag on the socket, and then tries to use the socket to > asynchronously connect to port 32767 on one of my servers. (The server > in question is _not_ running any sort of listener on that particular po= rt.) > > Eventually, after a suitable waiting period and a suitable number of > retries, the attempt to connect will fail, and the call to poll(2) > will then return. At that point, the program checks to see if the > POLLERR bit is set in the returned `revents' field of the pollfd > structure. > > An error has indeed occured... the connect DID NOT complete successfull= y... > so the POLLERR bit should be set, right? A connect() failure is not, as the FreeBSD man page puts it, "an exceptional condition" nor a "device error". And Linux, believe it or not, is not a good indication of what might be considered "standard behaviour". Hint: you program does not behave as you would like on Solaris 7, HP-UX 11 or AIX 4.3 either. If you want to write even remotely portable code, you should buy, beg, borrow or steal a copy of Stevens "UNIX Network Programming." There you will find a whole section on non-blocking connections, learn that they are somewhat painful to deal with correctly, and that your best bet on checking the status of a connect attempt is polling for read/write and using getsockopt() to check for error. $.02, /Mikko P.S. To answer your question: it is neither bug nor feature, it's just life :-) Mikko Ty=F6l=E4j=E4rvi_______________________________________mikko@rsase= curity.com RSA Security To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message