[EMAIL PROTECTED] wrote:
> 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.
The existing type SSL (aka struct ssl_st) is pretty close to what you
want. I'd like to use it for now rather than creating a new, cleaner
version. Also, rather than using an id, I'm pretty happy with the existing
scheme of using a pointer.
> 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.
I suspect the people working on the crypto-accelerator support
are putting together some plumbing which might let you use remote
CPUs, btw.
> 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.
If you look carefully, some of this has already been done. They *do*
support nonblocking I/O somewhat, so they really have added the states
you need. See e.g. ssl3_get_record().
> So we get something like these two control variables...
>
> ccb[id]->ccb.state, ccb[id]->ccb.status which is our error return.
SSL already has three fields (state, rstate, and rwstate).
> 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.
Isn't 'struct ssl_st' already an object with a 1-1 correspondence with
the connection?
We should probably take this off-list until we have more interesting
stuff for the group.
- Dan
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
