|
Home > Archive > Unix Programming > January 2004 > How do I know ECONNREFUSED from non-blocking connect?
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
How do I know ECONNREFUSED from non-blocking connect?
|
|
|
| Hi,
Probably an easy one for you lot... 
If I try a connect() on a non-blocking socket; how can I determine the error
ECONNREFUSED or ETIMEDOUT.
Should I get the socket option SO_ERROR after my select() call tells me
something has happened?
Thanks.
Steve.
| |
| Barry Margolin 2004-01-23, 5:02 pm |
| In article <BBD19E5C.44C94%postmaster@127.0.0.1>,
Steve <postmaster@127.0.0.1> wrote:quote:
>If I try a connect() on a non-blocking socket; how can I determine the error
>ECONNREFUSED or ETIMEDOUT.
>
>Should I get the socket option SO_ERROR after my select() call tells me
>something has happened?
I think when you call read() or write() after select() tells you the socket
is ready, you should get ECONNREFUSED or ETIMEDOUT.
--
Barry Margolin, barry.margolin@level3.com
Level(3), Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
| |
| Grant Taylor 2004-01-23, 5:02 pm |
| Steve <postmaster@127.0.0.1> writes:
quote:
> If I try a connect() on a non-blocking socket; how can I determine the error
> ECONNREFUSED or ETIMEDOUT.
>
> Should I get the socket option SO_ERROR after my select() call tells me
> something has happened?
Yes, exactly.
Note that, on Linux at least, you should not check the error value
before the socket is reported as writable. Before the socket reports
as writable, reading the error value gives no error, not even
EINPROGRESS as you might expect. This is in fact indistiguishable
from "happy connect", even when in fact the socket is not connected.
Similarly most any other socket operations will destroy the value, so
don't go reading or writing if you really want to know what the
connect result was.
IMHO, this interface is slightly irritating; if your event reporter is
in fact any sort of edge-triggered completion notification (such as
pre-2.6 linux epoll, or most of the signal-based schemes) it is
necessary to plug the socket fd into your interest set *between* the
socket() and connect() calls - something many higher-level libraries
make painful, since traditionally one does select or poll, where it
doesn't matter.
--
Grant Taylor - gtaylor<at>picante.com - http://www.picante.com/~gtaylor/
Linux Printing Website and HOWTO: http://www.linuxprinting.org/
| |
| James Chen 2004-01-23, 5:02 pm |
| If select returns 0, the timer expired and ETIMEDOUT is returned. At the
time, socket should be closed to prevent
the free-way handshake.
If the descriptor is readable or writable, call "getsockopt" to fetch the
socket's pending error(SO_ERROR). If the connection
completed successfully, this value will be 0. If the connection completed
successfully, this value is the errno value corresponding
to the connection error.
James
"Steve" <postmaster@127.0.0.1> wrote in message
news:BBD19E5C.44C94%postmaster@127.0.0.1...quote:
> Hi,
>
> Probably an easy one for you lot...
>
> If I try a connect() on a non-blocking socket; how can I determine the
errorquote:
> ECONNREFUSED or ETIMEDOUT.
>
> Should I get the socket option SO_ERROR after my select() call tells me
> something has happened?
>
> Thanks.
> Steve.
>
| |
|
| On 7/11/03 7:39 pm, in article uc65hwdl2v.fsf@habanero.picante.com, "Grant
Taylor" <gtaylor+cup_cdgie110703@picante.com> wrote:
quote:
> Steve <postmaster@127.0.0.1> writes:
>
>
> Yes, exactly.
>
> Note that, on Linux at least, you should not check the error value
> before the socket is reported as writable. Before the socket reports
> as writable, reading the error value gives no error, not even
> EINPROGRESS as you might expect. This is in fact indistiguishable
> from "happy connect", even when in fact the socket is not connected.
It'll be Mac OS X, actually.
quote:
> Similarly most any other socket operations will destroy the value, so
> don't go reading or writing if you really want to know what the
> connect result was.
OK.
quote:
> IMHO, this interface is slightly irritating; if your event reporter is
> in fact any sort of edge-triggered completion notification (such as
> pre-2.6 linux epoll, or most of the signal-based schemes) it is
> necessary to plug the socket fd into your interest set *between* the
> socket() and connect() calls - something many higher-level libraries
> make painful, since traditionally one does select or poll, where it
> doesn't matter.
I am actually writing a higher-level library!
The connect() is done in one thread, and the blocking select() is done in
another thread, so I can't guarantee that select() will be called before or
after connect().
Hmmm ... I hope the socket API is thread safe?
Steve.
| |
|
| On 7/11/03 9:31 pm, in article
UaUqb.2705$XDB.2696@news01.bloor.is.net.cable.rogers.com, "James Chen"
<chenzhijian@hotmail.com> wrote:
quote:
> If select returns 0, the timer expired and ETIMEDOUT is returned. At the
> time, socket should be closed to prevent
> the free-way handshake.
But I could have other sockets in the fd_sets.
quote:
> If the descriptor is readable or writable, call "getsockopt" to fetch the
> socket's pending error(SO_ERROR). If the connection
> completed successfully, this value will be 0. If the connection completed
> successfully, this value is the errno value corresponding
> to the connection error.
OK. Would the socket's SO_ERROR be ETIMEDOUT then?
quote:
> James
Cheers.
Steve.
| |
| David Schwartz 2004-01-23, 5:05 pm |
|
"Steve" <postmaster@127.0.0.1> wrote in message
news:BBD1C954.44FF8%postmaster@127.0.0.1...
quote:
> On 7/11/03 9:31 pm, in article
> UaUqb.2705$XDB.2696@news01.bloor.is.net.cable.rogers.com, "James Chen"
> <chenzhijian@hotmail.com> wrote:
quote:
>
> But I could have other sockets in the fd_sets.
I have no idea what James is talking about here, but it doesn't seem to
make any sense. The 'select' timing out tells you nothing about the progress
of the connection.
quote:
the[QUOTE][color=darkred]
completed[QUOTE][color=darkred]
>
> OK. Would the socket's SO_ERROR be ETIMEDOUT then?
If the connection attempt timed out, then it should be.
DS
| |
| Grant Taylor 2004-01-23, 5:05 pm |
| Steve <postmaster@127.0.0.1> writes:
quote:
[QUOTE][color=darkred]
> I am actually writing a higher-level library!
Ah, good, I got to one early ;)
quote:
> The connect() is done in one thread, and the blocking select() is
> done in another thread, so I can't guarantee that select() will be
> called before or after connect().
With select or poll it shouldn't matter, because you are given "yes,
there is an output event" any and every time you ask, rather than
"there is an output event" once per event. So you can easily avoid
calling getsockopt or read/write before the kernel has finished
connecting; just be sure to do it in every process or thread.
FreeBSD offers a "kqueue" mechanism, and I think can also do
signal-based completion notification. Certainly the signal thing, and
possibly kqueue events may be subject to the race I mentioned. Dunno
if either event mechanism was preserved by Apple.
quote:
> Hmmm ... I hope the socket API is thread safe?
Well, yes, arguably it always has been. The calls themselves refer
via file descriptors to state kept mostly in the kernel, so it has
always been save for multiple processes to share sockets in various
ways. When threads came along little needed changing.
--
Grant Taylor - gtaylor<at>picante.com - http://www.picante.com/~gtaylor/
Linux Printing Website and HOWTO: http://www.linuxprinting.org/
| |
|
| On 10/11/03 2:51 am, in article uche1ddjhl.fsf@habanero.picante.com, "Grant
Taylor" <gtaylor+cup_bbibj110903@picante.com> wrote:
quote:
> Steve <postmaster@127.0.0.1> writes:
>
> With select or poll it shouldn't matter, because you are given "yes,
> there is an output event" any and every time you ask, rather than
> "there is an output event" once per event. So you can easily avoid
> calling getsockopt or read/write before the kernel has finished
> connecting; just be sure to do it in every process or thread.
Okee dokee
quote:
> FreeBSD offers a "kqueue" mechanism, and I think can also do
> signal-based completion notification. Certainly the signal thing, and
> possibly kqueue events may be subject to the race I mentioned. Dunno
> if either event mechanism was preserved by Apple.
Maybe worth investigating, but I'd like to keep things as platform-neutral
as possible.
quote:
>
> Well, yes, arguably it always has been. The calls themselves refer
> via file descriptors to state kept mostly in the kernel, so it has
> always been save for multiple processes to share sockets in various
> ways. When threads came along little needed changing.
Make sense I suppose!
Thanks
Steve.
|
|
|
|
|