I'm trying to integrate OpenSSL into a nonblocking
server that already has a firm idea of how it wants
to do its networking. In other words, I want to
use OpenSSL, but *do not* want OpenSSL doing any
networking for me. I also don't want to use any
huge, ungainly abstractions such as BIO pairs.
What I want is a simple API that doesn't even
*think* it can do networking.
I have seen several people asking about nonblocking
support on this list over the last year or so. Here
are a few typical responses:
http://www.mail-archive.com/[email protected]/msg03423.html
http://www.mail-archive.com/[email protected]/msg04933.html
http://www.mail-archive.com/[email protected]/msg05515.html
http://www.mail-archive.com/[email protected]/msg07301.html
All of which are helpful, but none of which really do the trick.
OpenSSL seems bent on doing the networking for the user (or, with
BIO pairs, *thinking* it's doing the networking for the user),
but what I want to do is bypass all that.
According to a post by Geoff Thorpe, this is indeed what he has
done. See
http://marc.theaimsgroup.com/?l=openssl-users&m=94379957705047&w=2
> The easiest way to do this is
> (i) select on readability, and writeability only if there's data waiting
> to go.
> (ii) read everything that can read.
> (iii) grind the SSL state-machine
> (iv) write anything that can write and has something waiting to go.
> (v) gring the SSL state-machine again.
> (vi) go back to (i)
>
> I abandoned BIOs a while ago (where possible that is) and have my own
> comms/buffering wrapper so this is the way that works for me. The last
> recollection I have of s_client/s_server is some seriously mutated
> handling of stdin/stdout with the raw socket that was almost written the
> way it was as some sick exam question. It's actually pretty easy to write
> code that does the required job (ie. worry about one connection at a time
> only and just proxy stdin/stdout through an SSL state-machine), but
> somehow it's emerged in a form that is everything but self-explanatory.
> Having butted heads with the "state machine" side of it too I can
> appreciate why it may or may not be solid with respect to non-blocking IO.
> It has a few gotchas, and when the code looks like that it makes it
> difficult to rule them (gotchas) in or out.
I'm considering working out how to bypass all the crufty networking in
OpenSSL to allow better support for nonblocking I/O.
Has anyone else already done this? Is anyone else interested?
Thanks,
Dan
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
