Date: Thu, 28 Feb 2002 14:03:20 -0800 (PST) From: =?ISO-8859-1?Q?Mikko_Ty=F6l=E4j=E4rvi?= <mikko@rsasecurity.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>
next in thread | raw e-mail | index | archive | help
"Ronald F. Guilmette" <rfg@monkeys.com>:
> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020228140039.T93443-100000>