On Mon, Oct 27, 2008 at 11:03 PM, David Schwartz <[EMAIL PROTECTED]> wrote: > >> > 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
Excellent! Thanks a lot again, David. ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]