[EMAIL PROTECTED] wrote:
> > Whatever we come up with, I'm sure the classic OpenSSL API could
> > be layered on top of it. Perhaps we could consider this effort an
> > experimental refactoring of the OpenSSL codebase to improve its
> > quality and reusability.
>
> I agree with this approach. The threaded model is fine - and a very good
> idea for many situations. Also the idea of just opening the socket in ssl
> mode is the best way to handle client side communications. Lord knows as
> a programmer I would not want to have to deal with the complexity of
> non-blocking IO - it is simply overkill since a client only has to handle
> a few connections at a time.
>
> If the underlying code is properly constructed, the socket connect can run
> on top of it easily and it can support the thread model with no
> difficulty.
Yup.
> > That was my impression, too. I suggest we try to understand the existing
> > OpenSSL state machine, and come up with the tiniest possible bit of
> > code that puts the 'right' kind of interface on the existing functionality.
> > (Any bigger rewrite, and we'd never finish, I fear.)
>
> I usually find it easier to write from scratch.
Yes, but I'd like to try for an incremental approach, given that
we're messing with a code tree we're not all that familiar with.
Let's experiment by inserting the interface we're talking about
into the existing code and making sure it doesn't break existing
programs. Once the interface is happy, the stuff behind it could
be cleaned up further. I have nothing against total rewrites, but
I'm looking for something that integrates smoothly into the
mainline OpenSSL source tree and avoids duplicating code.
> In any event, if we design the proper underlying data structures to
> accomodate what we want - then all we need to do is pass this data
> structure into the proper state engine and the state engine can find the
> parameters the low level subs need and call them. It can even do this in
> a forked shared memory mode which is probably what we need. Either
> forked or multithreaded will therefore work because any instance of the
> low level functions will run in its proper memory and thus can run
> concurrently and on multi processors if required.
Sounds good to me. I especially want to be able to fob off the slow
crypto onto another thread. If we play our cards right, we can do
that *without any mutexes*, I bet.
> I have a more complex model in mind ...
> Since the database functions are already being exported, I want to export
> the crypto as well and have the server basically just do the connections
> and act as a traffic cop. ... the idea here is to create parallelism right
> from the moment the connection hits the server and I think it is a valid
> approach and openSSL should be able to support it.
I agree that OpenSSL should support parallelism, but only within a
single system; I'd prefer to avoid dealing with serializing connection
context state and sending it to other systems at the moment.
Can we stick to the kind of parallelism you can achieve on a single
motherboard + math accellerator cards for the moment?
Next step, I think, is to propose an interface that fits into the existing
code while letting the user control buffering and network I/O if desired.
ssl3_pkt.c is an interesting place to start looking, as it has
several routines that loop on BIO_ functions. Somehow I want to move
those loops and BIO_ calls *outside*, e.g. into a "classic OpenSSL"
module, which would call BIO_{read,write}, then call the new interface,
and loop as needed. Programs that wanted to control their own networking
and buffering would bypass the "classic OpenSSL" module, and call
the new interface directly.
- Dan
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
