> Some of the difficulties that I'm having revolve around the
> fact that the socket I/O code is
> integrated into the protocol code.
It really isn't. You can very easily use the SSL code just to do the SSL
stuff and do all the I/O yourself. The only feature you lose when you do
this is client connection reuse.
> Our applications are designed
> around a GSSAPI/SSPI model
> where the application does the I/O and gets buffers from the
> protocol provider and sends buffers
> to the protocol provider. Two specific situations where I have a
> problem with OpenSSL is that I had
> planned to tunnel SSL inside of another, application specific,
> protocol. I haven't been able to
> determine how to do this.
It's a bit tricky, but not impossible. All you have to do is create an SSL
structure and run a loop. When you receive SSL data, hand it to the SSL
code. When you have plaintext you want to send, hand it to the SSL code.
> Also, our servers can handle large
> numbers of clients concurrently.
> Because of this feature, I don't like the fact that it appears
> that a SSL call could bock my server
> unless I make the server multithreaded. The fact that the OpenSSL
> code contains so much static
> data make me wonder if OpenSSL is thread safe. Does anyone have
> an opinion on that?
If you really have a single process that handles large numbers of clients
concurrently, it would have to already be multithreaded. Otherwise, for
example, a single page fault would stall your entire server. If your server
does any disk I/O and encounters an NFS-mounted file, do you stall the whole
server while the read completes? If your server is 100% CPU and no blocking
I/O, then you can get away with a single thread, but then SSL won't change
anything. All it will do, if you don't let it do the I/O, is spin the CPU.
DS
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
