Marek Marcola wrote:
Your next argument will be:
"if you do select() and space shuttle is flying ..."
I am in complete agreement here.
The crux of the situation is that I'm (we're) saying its possible to
have working OpenSSL blocking mode that uses a blocking socket which
conforms the to host platforms select/poll/read/write event notification
characteristics. This is what I'm calling transparency.
Any quirks are also transparent, any application for that host would
already need to take into account those quirks, so quirks become a
non-issue too.
I'm saying the only reason this is the problem inside OpenSSL is that
one high level API call SSL_read()/SSL_write() may end up calling two
low level socket calls read()/write(), each of which may block.
In my wisdom of having written IO layers before in order to keep event
notification characteristics your first low-level call you make (per
high level invocation) you treat it will may block. Any futher low
level calls you want to make you must do so non-blocking or return -1
WANT_READ/WANT_WRITE.
Since OpenSSL can almost do full non-blocking mode as every part is
restartable then its 95% there to getting a transparent blocking mode
since the hard bit is already done. If this is not the case I would
vote to fix that too :).
All you have to do inside OpenSSL is know if your underlying IO mode is
blocking or non-blocking and set a flag everytime to you enter a
high-level call from the application context.
Then _BEFORE_ you issue any low-level I/O you test to see it your
low-level IO is in blocking mode and the flag is reset. If that
condition is true to return -1 and WANT_READ/WANT_WRITE depending on
what you just about to try and do.
Then _AFTER_ everytime you issue a low-level I/O (read or write) you
reset that flag.
You now get one I/O per high level call.
This may also expose/fix bugs within OpenSSL where non-blocking mode is
not correctly implemented and they never showed up before because 99% of
the time the other end of the connection sent a packet with all the data
we needed in it, so the successive read() never returned EAGAIN.
So maybe OpenSSL should have 4 IO modes.
* Non-blocking,
* Fully-blocking (with SSL_MODE_AUTO_RETRY, based on application data
through put),
* Spongey-blocking (as now without SSL_MODE_AUTO_RETRY),
* Transparent-blocking (one I/O per call, based on low level IO
throughput).
IMHO Spongey-blocking mode is of little practical purpose to anyone. It
blocks when you dont want it to and may sometimes return -1
WANT_READ/WANT_WRITE anyway.
I would vote to replace spongey-blocking mode with transparent-blocking
if my vote ever meant anything.
Darryl
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
