Dan - I agree with you whole heartly and this fact set me back tremendously. When I
looked at the code I was really disappointed that there appeared to be way too much
being done in the bowels of the api - and stuff that frankly does not belong there.
So the question is - how do we fix it?
On Sun, Nov 12, 2000 at 12:06:00AM -0800, Dan Kegel wrote:
> Dr S N Henson wrote:
> > > The revised OpenSSL ASN1 code will eventually have support for I/O based
> > > operations in addition to the current memory based operations which need
> > > to have the entire structure in memory (tricky if its a 1Gb structure on
> > > tape).
> > >
> > > Doing blocking I/O is fairly straight forward.
> > >
> > > Handling non blocking I/O is quite a bit harder because the ASN1 decoder
> > > or encoder must be able to save its internal state and restart where it
> > > left off.
> > >
> > > So the question: how many people would want non blocking I/O support? If
> > > no one or hardly anyone wants or needs it then there isn't a lot of
> > > point. However if there's considerably demand it would be worth looking
> > > into.
> >
> > My comments refer to ASN1 I/O only. OpenSSL doesn't currently have I/O
> > based ASN1 code at all and I'm seeing if people have a specific need to
> > non blocking ASN1 I/O or if the simpler blocking I/O will suffice.
>
> Can you give us an example of how ASN1 I/O would be used?
> I'm having trouble imagining, since I'm from a land very far from ASN1.
>
> I will say, though, that when writing protocol modules, I prefer to
> keep them WAY far separated from I/O, and make them able to handle
> arbitrary chunks of data. In general I'd prefer an api that
> made it possible for me to do my own nonblocking I/O and pass the results
> to the api rather than an API that tries to do I/O for me.
>
> Which reminds me of BIO's. (Uh-oh, he got me started!)
> Yes, they are very handy, but they have no place in the core of an SSL API,
> because for apps that use nonblocking I/O, they make it very hard
> for the app to control what's going on. (Yes, I've seen the state demo.)
> In particular, from what I know so far, the app is unable to have one
> thread execute the 'cheap' parts of OpenSSL, and another execute
> the expensive crypto parts, partly because OpenSSL uses BIOs internally.
> This gets to be a bit of a problem when you're pushing the limits, trying to
> handle thousands of sessions with a handful of threads.
>
> BIO's should have been a well-separated layer, not an integral part of OpenSSL.
> Don't repeat the same error with any new design.
>
> - Dan
> ______________________________________________________________________
> OpenSSL Project http://www.openssl.org
> Development Mailing List [EMAIL PROTECTED]
> Automated List Manager [EMAIL PROTECTED]
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
