Jeffrey Altman wrote:
>
> > > I'd prefer to bypass all OpenSSL-internal buffering and I/O entirely,
> > > and let the app do all the buffering and I/O.
> >
> > Maybe, but I'm not sure what you mean exactly. Could you describe
> > in terms of an approximate example API?
>
> I think what he would like is the ability to do what the Microsoft
> SSPI does. Instead of OpenSSL being a layer between the I/O channel
> and the app, he would like the app to provide all I/O functions and
> have OpenSSL provide routines that encode and decode buffers provided
> to it by the application. After OpenSSL has done its work, the
> application transmits the outgoing data to the peer. After receiving
> data from the peer it calls OpenSSL to process it.
>
> Its a different model which has its advantages when working with
> applications that may not have direct access to the network socket and
> instead have its I/O handle by message passing.
That's right.
I may start by writing a benchmark program which measures performance
of OpenSSL in my kind of server environment. This will illustrate
the accepted way to use OpenSSL with nonblocking sockets.
Then if I'm still unhappy, I'll propose the alternate API and
show how it would simplify the server code.
- Dan
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
