> > stuff and do all the I/O yourself. The only feature you lose when you do
> > this is client connection reuse.
>
> is it really so? i allways thought that session caching is implemented
> completely in ssl statemachine.
Yes, it's really so. The problem is that if you do all the network I/O, the
SSL code has no idea what session to reuse (since it doesn't know who it's
talking to). This isn't a problem for the server code because it's the
client's responsibility to suggest a session to reuse. It's not impossible
to workaround this, but it's a pain and, IMO, generally not worth the effort
unless your specific application really needs it.
> > 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.
>
> yes it will. asymmetric cryptography is quite time-consuming and you task
> will hang for quite a long period when performing rsa, dsa or dh
> calculations.
True, but that's a problem with single-threaded applications in general.
This is the reason that it's almost impossible to code a robust real-world
server-type application with a single process and a single thread.
DS
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
