> > I was thinking about an alternate solution, using blocking sockets,
> > and doing the connect on another thread. If the user cancels the
> > operation I'd close the socket (BIO_free) and I guess the connect
> > would return with an error and the thread would exit then. Seems a
> > little dirty but it could simplify my life. What do you think?
> >
> > Cheers,
> > Gabriel.
>
> I wouldn't recommend that for three reasons. First, you may be on
> a platform
> that doesn't support threads or doesn't support threads well.
> Second, there
> will always be a race window where the user might close the
> socket right as
> you're about to call 'connect'. If that happens, you may wind up
> 'connect'ing somoene else's socket. Third, it has a complexity and
> hackishness that increases the risk that odd things will happen.
>
> Calling 'getpeername' is a pretty common way to determine if a socket is
> connected.
>
> DS
I just realized that I misunderstood you. Yes, that's a perfectly sensible
workaround to use in your own code, so long as you can deal with the race
condition issue.
Here's a patch to crypto/bio/bss_conn.c that you can test:
--- old/bss_conn.c 2008-10-27 17:55:22.000000000 -0700
+++ new/bss_conn.c 2008-10-27 17:57:18.000000000 -0700
@@ -291,9 +291,20 @@ static int conn_state(BIO *b, BIO_CONNEC
ret=0;
goto exit_loop;
}
else
+ {
+ struct sockaddr sad;
+ socklen_t l=sizeof(sad);
+ if(getpeername(b->num, &sad, &l)==0)
c->state=BIO_CONN_S_OK;
+ else
+ {
+ BIO_set_retry_special(b);
+
b->retry_reason=BIO_RR_CONNECT;
+ goto exit_loop;
+ }
+ }
break;
case BIO_CONN_S_OK:
ret=1;
DS
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
