On Mon, Sep 11, 2000 at 02:49:24PM +0300, Wirta, Ville wrote:
> Netscape and IE both cache sessions and the server you are writing
> should as well. I believe most sane browsers would do the same.
> Unless you are writing your own client, you really don't have to worry
> about client-side caching.
> Let's say your server caches sessions. If the browser doesn't re-use
> a session, the entire handshake would be repeated for every connection.
> OpenSSL library will take care of that for you.
>
> I'd like to know if the browsers IE and Netscape do reuse the
> sessions because otherwise it's pretty useless for me taking that SSL-cache
> into use. Do you happen to know if they do or not?
They do, as I tried to send you in private mail, but unfortunately there
seems to be some problem with your email setup:
Hi. This is the qmail-send program at mail2.novogroup.com.
I'm afraid I wasn't able to deliver your message to the following addresses.
This is a permanent error; I've given up. Sorry it didn't work out.
<[EMAIL PROTECTED]>:
62.236.76.34 does not like recipient.
Remote host said: 554 Mailbox unavailable.
Giving up on 62.236.76.34.
I have append the text of the mail, maybe you receive it this way:
On Mon, Sep 11, 2000 at 01:47:09PM +0300, Wirta, Ville wrote:
> I don't suppose you know if Netscape and IE support SSL-ses-caching? Do you?
> Do they? :-)
They support session caching. Otherwise people would have shot the authors
for the problem you describe below :-)
> Btw, isn't this SSL session caching actually another cure (with the
> HTTP-part connection-keep-alive) for the same disease --> slow connections?
> If the connection is kept alive there is no need to do caching I suppose? My
> server does'nt yet support keep-alive and therefore f.ex. every picture in a
> www-page generates a new SSL_handshake with the long asym. keys (because
> every item generates a new HTTP GET). Session caching could help but
> implementing the keep-alive makes the problem disappear. What do you think?
> Am I correct? And do you think it is generally so that when people talk
> about their servers in the OpenSSL-newsgroup they are not talking about
> web-servers and therefore the keep-alive cannot help them which makes
> SSL-ses-cache useful?
I am not always sure what kind of servers people are talking about.
There is apache with mod_ssl (Ralf Engelschall) and Apache/SSL (Ben Laurie).
Both support session caching. With respect to other services: the most
significant problem are a lot of connections for short items like web pages
with lots pictures.
I deal with SMTP connections, which are not that frequent. I have session
caching running on both the server side and the client side and I can tell
you, that things are really sped up by using session caching.
Two HP-UX workstations (C180 class) need approximately 1 second to negotiate
a session, so email delivery is delayed for that time. Once the session is
cached, there is no noticable delay anymore (until it expires and a new
session must be negotiated).
If you have a protocol like imap, the session is opened once and can then
be kept open for a long time, so the negotiation cost can be acceptable.
For your multi-threaded server, I don't see a problem. Your clients (NS and
IE) support caching. As far as I know, OpenSSL is thread safe (never used
threading myself), so session caching can be quite easy.
If you can go down to 128 cached session at the time (you have to estimate
that), you may be happily living with the included memory cache as
described in doc/ssleay.txt. If you need more, you must store the sessions
externally and reuse them.
I have spend quite some time documenting my Postfix/TLS source code, maybe
you can take some hints from it.
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
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
