On Mon, Oct 27, 2008 at 11:03 PM, David Schwartz 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 majordomo@openssl.org