You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by Jeff Trawick <tr...@attglobal.net> on 2001/08/06 23:22:17 UTC
Re: [PATCH] sockets.c
barbee@veribox.net writes:
> There shouldn't be a reason to call connect again in the chunk
> below since apr_wait_io_or_timeout should return success if we can
> use the socket or error if we've timeout.
The purpose of the connect call is to find out whether or we have a
connection. It is much better to find an error (e.g., ECONNREFUSED)
here than have a subsequent read or write fail. Applications don't
tend to have as friendly an error path when send or recv fail as they
do when connect fails since a connect failure is normal behavior (user
specified bad input).
--
Jeff Trawick | trawick@attglobal.net | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
Re: [PATCH] sockets.c
Posted by Ryan Bloom <rb...@covalent.net>.
I watched it fail on a FreeBSD machine.
For an example of code that uses a non-blocking accept:
http://www.cs.odu.edu/~cs779/stevens2nd/lib/connect_nonb.c
Ryan
On Monday 06 August 2001 14:48, Jeff Trawick wrote:
> Ryan Bloom <rb...@covalent.net> writes:
> > The problem is that the second connect() call is failing with an
> > EALREADYCONNECTED. The correct way to detect an error from connect,
> > according to Single Unix, is to do a poll or select. If select/poll
> > return with an error or they timeout, the connect failed. If they return
> > successfully, then the connect has succeeded.
>
> On what platform is it failing with EALREADYCONNECTED? I can't
> readily reproduce this problem. (not disagreeing, just would like to
> play with it myself)
>
> A patch to look for an error in a different manner must retrieve the
> saved error from TCP. You gotta get the ECONNREFUSED or ENETUNREACH
> back to the app.
>
> (Actually, when I did this code I did look around for examples.
> I guess I looked at a bad one :) )
>
> By the way... Stevens doesn't check for exception on the socket, just
> readability and writability, then he calls getsockopt(,SOL_SOCKET,
> SO_ERROR,) to retrieve the saved error from TCP.)
--
_____________________________________________________________________________
Ryan Bloom rbb@apache.org
Covalent Technologies rbb@covalent.net
-----------------------------------------------------------------------------
Re: [PATCH] sockets.c
Posted by Jeff Trawick <tr...@attglobal.net>.
Ryan Bloom <rb...@covalent.net> writes:
> The problem is that the second connect() call is failing with an EALREADYCONNECTED.
> The correct way to detect an error from connect, according to Single Unix, is to do a poll
> or select. If select/poll return with an error or they timeout, the connect failed. If they return
> successfully, then the connect has succeeded.
On what platform is it failing with EALREADYCONNECTED? I can't
readily reproduce this problem. (not disagreeing, just would like to
play with it myself)
A patch to look for an error in a different manner must retrieve the
saved error from TCP. You gotta get the ECONNREFUSED or ENETUNREACH
back to the app.
(Actually, when I did this code I did look around for examples.
I guess I looked at a bad one :) )
By the way... Stevens doesn't check for exception on the socket, just
readability and writability, then he calls getsockopt(,SOL_SOCKET,
SO_ERROR,) to retrieve the saved error from TCP.)
--
Jeff Trawick | trawick@attglobal.net | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
Re: [PATCH] sockets.c
Posted by Ryan Bloom <rb...@covalent.net>.
The problem is that the second connect() call is failing with an EALREADYCONNECTED.
The correct way to detect an error from connect, according to Single Unix, is to do a poll
or select. If select/poll return with an error or they timeout, the connect failed. If they return
successfully, then the connect has succeeded.
Ryan
On Monday 06 August 2001 14:22, Jeff Trawick wrote:
> barbee@veribox.net writes:
> > There shouldn't be a reason to call connect again in the chunk
> > below since apr_wait_io_or_timeout should return success if we can
> > use the socket or error if we've timeout.
>
> The purpose of the connect call is to find out whether or we have a
> connection. It is much better to find an error (e.g., ECONNREFUSED)
> here than have a subsequent read or write fail. Applications don't
> tend to have as friendly an error path when send or recv fail as they
> do when connect fails since a connect failure is normal behavior (user
> specified bad input).
--
_____________________________________________________________________________
Ryan Bloom rbb@apache.org
Covalent Technologies rbb@covalent.net
-----------------------------------------------------------------------------