David,
If I can get 999% guarantee, I'd be happy. Not looking for the
impossible 100%.
In any case, yes, you've pegged the heart of my real question. And, your
answer is not the one I was hoping for but it has the authoritative
flavor that I ultimately really wanted, regardless of the answer. Thank
you! 100% non-blocking it is then. I'll start wrapping them up now.
Thanks a million David!
Joe
P.S. I remember writing a socket program on Netware many years ago (that
we still use on several servers to this day) that required connect() in
the non-blocking section or it would fail sometimes although very rare.
I suppose I was trying to forget that here.
David Schwartz wrote:
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]
