> David Schwartz wrote:
> > I have never done anything like this, however.
> >
> > DS
> >
> Hmmmm..... Then, I'm curious to know at what point (between what socket
> functions) you put your socket in the non-blocking state and when/if you
> ever set it back to blocking?
>
> Joe
I almost always use a 100% non-blocking architecture. There are few if
any
advantages to blocking indefinitely. The only exception is on Windows, where
there used to be no 'ConnectEx'-type function that would make an outbound
connection using IOCP.
I think your question comes down to whether there is an absolute
guarantee
that making a connection and closing a connection are always guaranteed to
complete after some limited amount of time. This is a more complex question
than you might think at first. If, for example, the SSL_connect function
ever calls 'read', then you're sunk. I'm pretty sure SSL_accept does try to
read, so it can block indefinitely.
I strongly caution you that if you don't want to ever block
indefinitely,
you should always use non-blocking operations. Otherwise, you risk writing
code that can be made to block should a circumstance you didn't think of
arise. In principle, any blocking operation can block indefinitely as it is
only supposed to return when it is certain that the requested operation can
or cannot complete. Most of the functions that are exceptions (like 'close')
are not always exceptions, and it's dangerous to rely on them always timing
out.
I would strongly advise you to put in the extra effort to make
everything
non-blocking (except perhaps a raw TCP 'connect' prior to any 'read's,
'write's, or SSL functions of any kind). I believe even SSL_accept and
SSL_connect can make calls down to 'read' to do the SSL negotiation.
DS
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
