Geoff Thorpe wrote:
> Well the sample size is not immense, but internally hardware usually
> functions in an async manner, and typically the APIs/SDKs are such that
> you can use the stuff in that way. I think you'll find if you delve into
> the vendor_defn/ headers in the engine stuff, and look at the hw_**.c
> implementations, you'll see that blocking forms of the API functions have
> been used in all cases ...
yep. The headers don't define the nonblocking forms. Guess I'd have
to get the SDK's to see how they work.
> > > non-blocking IO on its encrypted streams, then it is certainly possible to
> > > make it cope with a single new state that won't budge until the
> > > async_public_key_op_query() returns ASYNC_OP_FINISHED.
> Yeah, and I've just been trying to sift my way through the ssl/ code to
> work out just how amenable the code is to that. In principle, no problem.
> In practice, I dunno, I feel kind of violated after looking so deeply into
> ... *that* ...
I feel kind of violated after looking too hard at the OpenSSL code, too.
That's one reason I'm motivated to try to find a way to reduce its complexity.
> ... But until we solve the async interface problem - this
> only scales on the application side by using multiple threads and
> processes - and you way wish to scale your key-operation throughput a lot
> further than you wish to scale your use of threads and processes.
My server is structured with one thread doing all the networking, and
another thread doing the disk I/O. All the threads communicate via
simple queues; my goal is to have no mutexes except for the ones protecting
the queues. I could easily imagine adding one thread managing the crypto hardware
if all it did was feed queued ops to the hardware and suck the results
back out. It could even block waiting for the next result from the hardware
without affecting anything. That should scale to as many clients as I like,
while still using only three threads.
> ... If you've got a number of SSL statemachines sitting in a line and
> operating in just one thread using non-blocking IO - then the select()
> loop (or windows message-handler, or whatever) could be driven by activity
> on the file-descriptors/sockets *and* also using timeouts (or WM_IDLE in
> Win32?) to check up on SSL statemachines that were last left with an async
> public key operation in progress. That's not hard to do, and doesn't
> require hardware/driver/engine notification. It certainly doesn't require
> bug-ugly surrender contexts, or the use of callbacks and/or signal
> handlers from the engine itself when a result has arrived - in fact, such
> a back-to-front way of handling async operation is far more difficult to
> code around safely from the application's point of view. It's far more
> likely the application can figure out the time and place it most wishes to
> check up on pending public key operations.
What's wrong with having the engine simply place results in an event
queue for the app to pick up at its leisure?
> > My API proposal was meant to generate discussion. I realize it's not an
> > especially practical direction to move OpenSSL in. Does the idea of
> > an event-driven SSL API appeal to anybody, at least in the abstract?
>
> Well, we nearly have a purely non-blocking model available to us, were it
> not that sometimes our API calls just hang waiting for public key
> operations to return. And with a slick non-blocking model, it's not that
> hard to build an event-driven wrapper around the outside.
Ah, but consider this: I have the feeling that much of the kludginess of
the OpenSSL code is there to handle the fact that input arrives not
as whole SSL Record Layer units, but in dribs and drabs, and lots of
effort is expended in tracking where you are, and being able to resume
at that point in the middle of a record on the next call.
In a purely event-driven model, where the events corresponded to full
SSL Record Layer units, there'd be none of that fractional state saving
going on. The state machine would suddenly start looking less like spaghetti
and more like a textbook example of how the SSL protocol works.
While you could implement an event-driven API on top of classic OpenSSL,
it's not interesting to me. I'm mostly interested in it as a vehicle for
exploring how to make the OpenSSL source more comprehensible.
The SSL_peek() function, for instance, is broken, and nobody has shown
the slightest interest in fixing it. I can sympathize, because it's really
hard to understand. The corresponding bug in SSL_read() was fixed long ago,
and SSL_peek has diverged so far it's not clear how to carry the fix over.
In the purely event-driven API I'm imagining, the SSL_peek function wouldn't
even exist in the core API; it would be relegated to a simple convenience
layer on top of the event-driven API. So the core gets simpler and less
buggy, and the methods that were buggy move out to the periphery where
they no longer are hard to fix.
- Dan
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
