> > 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.
Yup - I think we can contain this quite easily. I'll grab the new source
tree asap and start looking over it with you. WHere we need to start is a
proper design for the datastructures. I like creating a group of function
calls with a not too long mnemonic... perhaps something like ccb
(connection control block) and we write up: ccb_create(int ccbid),
ccc_destroy(int ccbid)... everything that is required for this connection
control block gets stuffed into a data structure indexed by id. This
allows high level routines to cross refence the connection id (however it
is created) with the ccbid. inside the ccb data structure the
controller functions can find everything they need to stuff the crypto
functions. This makes it very easy for a controller function to grab some
studd for the existing bio code.
Overhead for this is trivial...
The idea I'd use is that a function that needs some memory can grab the
ccbid and pass it along with the memory request into a malloc wrapper. I
suspect this is done in a fashion because I've come across refences to a
malloc replacement that tracks leaks. With what I'm thinking, the
ccb_destroy function is responsible for any and all cleanup. If there are
memory leaks - they are flagged and cleaned up in ccb_destroy and if there
are no memory leaks - well - then ccb_destroy has nothing to do.
We can use a define to grab the ccbid parameter and pass it along with the
normal parameters into the malloc wrapper. This should be very easy to
layer into the existing code base.
In addition, by throwing some smarts into the malloc wrapper we _should_
be able to collect all these memory allocations into a nicely organised
group - which I want because I want to add a ccb_export and a ccb_import
that will fire the thing out the back door to 1) another process (deamon)
or 2) another computer.
With this done the driver functions basically become a case statement
which is trivial to write.
If we look at the existing serial code it will look like:
do A, send msg out bio function, wait for response
do B, send msg out bio function, wait for response.
All we need to to is break these steps into a case statement and post the
"next" step into the state field.
So we get something like these two control variables...
ccb[id]->ccb.state, ccb[id]->ccb.status which is our error return.
ccb_create sets ccb[id]->ccb.state = 0;
and our control function has a case statement which steps us through the
steps.... real trivial to do.
Finally, the top level controller does two things. I checks the status
comming oiut of openSSL and if it finds a fatal failure, it calls
ccb_destroy and the destructor blows away everything about this connection
- the connection has failed. there is no need for an orderly shutdown
other than the communications layer may send a nice message to the client
telling them (if they are still there) that something failed.
Finally, the communication side can time the connection. If the
connection times out, then the timer calls ccb_destroy and blows away the
connection and makes the ccbid number available again (clears the bit in
the select bitmap - or removes it from a table depending on how that is
implemented)
In all cases, memory leaks are completely controlled and at the same time
we simplify building or tearing down a connection.
----------
I think the key here is getting the datastructures collected into (for
lack of a better term) an "object" that has a 1-1 correspondence with the
connection.
Once this is done - the code base should be easy to upgrade. Not only
that - with this model anyone working with the existing code base can
either write - or we can write a ccb_dumper routine that will allow easy
inspection of what the state of the connection is.
----------
Now - we need to analyse the steps that a connection goes through. One way
is to use a heirarchical state number. say we allocate a max 10 steps
through any algorithm and allocate say a max of 3 branch tress. Then we
get a state number that looks like nnn with the first n identifying the
algorithm and the second n identifying the step within said alorithm and
the third teh substep etc.
I would call this a "top down" approach...
ANother approach is that the agorithm control block (inside the ccb)
contains its own stepper and this gives total freedom to the algorithm.
In this case the ccb_create function specifies - no algorithm
negotiated... (derived in the driver because it is in the initalization
state. Once the algorithm has been negotitated then the connection stays
in that state until connection gets closed and we have simply mulitply
nested case statements appropriate for each specific algorithm.
We can start on this right now I think.
And I agree 100% - we go our own way and build it - but in cooperation -
as we go people can particiapate or make suggestions and if it looks like
it is a good idea - it can eventually replace the existing code tree at
some point - or fork - however people want it.
remember - cleanup of busted connections may be tricky... in once case the
connection layer has to do it - in the other the bio layer has to do it...
In one case the top level application wants control and in the other case
all the top level wants to know is that the connection is gone and things
are back to normal - tell the user so sorry. These are quite divergent in
their implementation and we need to plan it out right.
ttys.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
