Gnat.Sockets and non-blocking connects

Gnat.Sockets and non-blocking connects

[Jano]

Hello!

I posted some time ago about non-blocking connects, and all went well. 
However, I have faced a new necessity I'm not sure how to address.

I'm trying to determine if a asynchronous connect has failed. When it 
ends successfully, I detect it with a select checking for writeability. 
However, it seems I must check the exception set to detect failure. 

The problem is that Gnat.Sockets doesn't implement the exception 
selector in its Select.

Any workarounds? I can't figure one right now.

TIA,

-- 
-------------------------
Jano
402450.at.cepsz.unizar.es
-------------------------

Re: Gnat.Sockets and non-blocking connects

[Florian Weimer]

Jano <nono@celes.unizar.es> writes:

> I'm trying to determine if a asynchronous connect has failed. When it 
> ends successfully, I detect it with a select checking for writeability. 
> However, it seems I must check the exception set to detect failure. 

No, this is a misunderstanding.  The exception set is not for error
reporting, but for exceptional situations.

Errors are reported by the R/W selectors.  However, nonblocking
connect error reporting is not portable, see Steven's UNIX Network
Programming.

Re: Gnat.Sockets and non-blocking connects

[Samuel Tardieu]

>>>>> "Florian" == Florian Weimer <fw@deneb.enyo.de> writes:

Florian> Errors are reported by the R/W selectors.  However,
Florian> nonblocking connect error reporting is not portable, see
Florian> Steven's UNIX Network Programming.

In practice, it *is* portable.

Jano, you need to check the write set, and try to connect again. You
will get an error. If the error is EISCONN, you *are* connected. If
this is anything else, you *aren't*.

  Sam
-- 
Samuel Tardieu -- sam@rfc1149.net -- http://www.rfc1149.net/sam

Re: Gnat.Sockets and non-blocking connects

[Florian Weimer]

Samuel Tardieu <sam@rfc1149.net> writes:

>>>>>> "Florian" == Florian Weimer <fw@deneb.enyo.de> writes:
>
> Florian> Errors are reported by the R/W selectors.  However,
> Florian> nonblocking connect error reporting is not portable, see
> Florian> Steven's UNIX Network Programming.
>
> In practice, it *is* portable.

The SO_ERROR socket option is implemented in two different ways.

> Jano, you need to check the write set,

Correct.

> and try to connect again. You will get an error. If the error is
> EISCONN, you *are* connected. If this is anything else, you
> *aren't*.

Unfortunately, you don't get the error code in this case.

Re: Gnat.Sockets and non-blocking connects

[Jano]

Florian Weimer dice...
> Samuel Tardieu <sam@rfc1149.net> writes:
> 
> >>>>>> "Florian" == Florian Weimer <fw@deneb.enyo.de> writes:
> >
> > Florian> Errors are reported by the R/W selectors.  However,
> > Florian> nonblocking connect error reporting is not portable, see
> > Florian> Steven's UNIX Network Programming.
> >
> > In practice, it *is* portable.
> 
> The SO_ERROR socket option is implemented in two different ways.
> 
> > Jano, you need to check the write set,
> 
> Correct.
> 
> > and try to connect again. You will get an error. If the error is
> > EISCONN, you *are* connected. If this is anything else, you
> > *aren't*.
> 
> Unfortunately, you don't get the error code in this case.

Mmm, I've found two workarounds for Windows:

* Trying to connect again will give an error while connecting, or will 
return again Operation_would_block (that means you have failed and are 
trying again, so it's kinda lame solution).

* Getting the remote address of the socket gives two different errors 
when connecting and failed.

Remember, I have no problem detecting the connection is successful. (My 
comments about the exception set were taken directly from the Windows 
help for Select).

However, I suppose that will not work in Linux. Oh well, really I hope 
these folks can get right a nice networking package for 0Y.

-- 
-------------------------
Jano
402450.at.cepsz.unizar.es
-------------------------

Re: Gnat.Sockets and non-blocking connects

[Florian Weimer]

Jano <nono@celes.unizar.es> writes:

>> Unfortunately, you don't get the error code in this case.
>
> Mmm, I've found two workarounds for Windows:
>
> * Trying to connect again will give an error while connecting, or will 
> return again Operation_would_block (that means you have failed and are 
> trying again, so it's kinda lame solution).
>
> * Getting the remote address of the socket gives two different errors 
> when connecting and failed.

Even on Windows, you can use getsockopt(2) and SO_ERROR.  No need to
jump through hoops. 8-)

Re: Gnat.Sockets and non-blocking connects

[Samuel Tardieu]

>>>>> "Florian" == Florian Weimer <fw@deneb.enyo.de> writes:

Florian> Even on Windows, you can use getsockopt(2) and SO_ERROR.  No
Florian> need to jump through hoops. 8-)

Even on Windows, you do not need to use SO_ERROR :) Just test
connect() return code.

  Sam
-- 
Samuel Tardieu -- sam@rfc1149.net -- http://www.rfc1149.net/sam

Re: Gnat.Sockets and non-blocking connects

[Florian Weimer]

Samuel Tardieu <sam@rfc1149.net> writes:

>>>>>> "Florian" == Florian Weimer <fw@deneb.enyo.de> writes:
>
> Florian> Even on Windows, you can use getsockopt(2) and SO_ERROR.  No
> Florian> need to jump through hoops. 8-)
>
> Even on Windows, you do not need to use SO_ERROR :) Just test
> connect() return code.

It's EINPROGRESS.  Pretty informative, isn't it?

BTW, "Cc: sam@rfc1149.net" deliberately bounces.  You might want to
fix your mail/news setup.

Re: Gnat.Sockets and non-blocking connects

[Samuel Tardieu]

>>>>> "Florian" == Florian Weimer <fw@deneb.enyo.de> writes:

Florian> It's EINPROGRESS.  Pretty informative, isn't it?

It's never EINPROGRESS if you wait until the corresponding bit is set
by select in the write set.

Florian> BTW, "Cc: sam@rfc1149.net" deliberately bounces.  You might
Florian> want to fix your mail/news setup.

It doesn't bounce.

  Sam
-- 
Samuel Tardieu -- sam@rfc1149.net -- http://www.rfc1149.net/sam

Re: Gnat.Sockets and non-blocking connects

[Jano]

Samuel Tardieu dice...
> >>>>> "Florian" == Florian Weimer <fw@deneb.enyo.de> writes:
> 
> Florian> It's EINPROGRESS.  Pretty informative, isn't it?
> 
> It's never EINPROGRESS if you wait until the corresponding bit is set
> by select in the write set.

It's never EINPROGRESS in my experience: the first time is "would 
block", following times is another one (invalid parameter I seem to 
remember but I'm not sure; certainly nothing like "in progress").

Checking for writing is ok for connects that succeed. For failed ones, 
you must check another thing. The windows SDK says to check for 
exception condition in select. Checking for reading or writing doesn't 
reveal the failure.

-- 
-------------------------
Jano
402450.at.cepsz.unizar.es
-------------------------

Re: Gnat.Sockets and non-blocking connects

[Jano]

Florian Weimer dice...
> Jano <nono@celes.unizar.es> writes:
> 

> Even on Windows, you can use getsockopt(2) and SO_ERROR.  No need to
> jump through hoops. 8-)

I must look at that!

Re: Gnat.Sockets and non-blocking connects

[Jano]

Jano dice...
> Florian Weimer dice...
> > Jano <nono@celes.unizar.es> writes:
> > 
> 
> > Even on Windows, you can use getsockopt(2) and SO_ERROR.  No need to
> > jump through hoops. 8-)
> 
> I must look at that!

It reports Connection_Refused, a much cleaner solution. Thanks!

-- 
-------------------------
Jano
402450.at.cepsz.unizar.es
-------------------------