This is a discussion on RE: Simple non-blocking TCP connect - Openssl ; > > 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 > ...
> > 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
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
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
+ struct sockaddr sad;
+ socklen_t l=sizeof(sad);
+ if(getpeername(b->num, &sad, &l)==0)
+ goto exit_loop;
OpenSSL Project http://www.openssl.org
User Support Mailing List email@example.com
Automated List Manager firstname.lastname@example.org