> You won't get non-blocking behaviour... The SSL 2 version... The selet()
> result is valid only for the first iteration, the second interation
> may block despite of what select() said.
I'm aware of these behaviours, but we aren't seeing blocking. It's very
evident when it does block, because the same thread is running both a GUI
and an Internet SSL connection. The only explanation is that when an SSL
message is sent, it *all* gets through or none (which means that perhaps,
sometimes, it actually does block until TCP fixes up the lost fragments,
but this blocking isn't "noticable").
We're using SSL3 (never 2), and although the protocol has some synchronisation,
it is fully peer-peer (application-level messages can be initiated on a
quiescent link by either party). In other words, blocking for long periods
would be a major problem. BTW, this has been running home banking for tens of
thousands of German clients of two different banks for several years now, so I
think they would have noticed and complained if the GUI froze...
> Now typically you won't
> notice this as the TCP peer usually will send data in complete SSL
> records so that the loop doesn't block endlessly, but if it stops a
> little bit too early it can make your process block. You can avoid
> this (if you want) by using non-blocking I/O.
This is the only real explanation of the acceptable behaviour we're seeing.
> > && LastError() != WOULDBLOCK)
> I don't think you'll ever see EWOULDBLOCK if you aren't using
> non-blocking sockets. BIO_should_retry can only mean EINTR in the
> situation that you described.
Interesting. The EWOULDBLOCK test wasn't needed with SSLeay-0.6.6, but
definitely is needed with 0.8.1.
> Sorry. Either you have code that accepts blocking (because the
> application protocol you're running on top of SSL is sufficiently
> synchronized, e.g. HTTP where there can't be disagreement between both
> parties where a request ends, amd you don't have to multiplex for
> various concurrent connections), or you'll have to use non-blocking
> I/O.
Neither of these is entirely true. Perhaps loss of part of an SSL packet
does cause blocking, but not for so long (before TCP fixes it) that the
effect on the GUI is noticable. So the method I've describe does work,
and may in fact be suitable for other applications. The only reason I
wrote is because I'd like the method to continue "working" as well as it
does.
> And if SSL 3 or TLS is used, things become more compliated, as
> there's always the possibility that a new handshake is started.
Not in this case I think, because we control both ends and don't renegotiate.
--
Clifford Heath http://www.osa.com.au/~cjh
Open Software Associates Limited mailto:[EMAIL PROTECTED]
29 Ringwood Street / PO Box 4414 Phone +613 9871 1694
Ringwood VIC 3134 AUSTRALIA Fax +613 9871 1711
------------------------------------------------------------
Proven Solution Deployment for the Global Enterprise
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
