On Mon, Oct 23, 2000 at 02:36:56PM -0700, David Schwartz wrote:
>
> > > 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.
The SSL code does not care at all about the underlying socket connection.
The client does never suggest a session to reuse unless the application
explicitly sets the session before calling SSL_connect().
The server side only uses the session ID for identifying the session to
be reused. It never looks for the socket.
Actually, the SSL machine only communicates with an underlying BIO which
can be a socket BIO. It can be a memory based BIO to. The SSL machine
does not have the slightest idea of what is socket is :-)
(I am using the wording "SSL machine" to not confuse it with the "engine"
release of OpenSSL...)
Best regards,
Lutz
--
Lutz Jaenicke [EMAIL PROTECTED]
BTU Cottbus http://www.aet.TU-Cottbus.DE/personen/jaenicke/
Lehrstuhl Allgemeine Elektrotechnik Tel. +49 355 69-4129
Universitaetsplatz 3-4, D-03044 Cottbus Fax. +49 355 69-4153
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
