Hi there,
On Fri, 7 Sep 2001, MATHIHALLI,MADHUSUDAN (HP-Cupertino,ex1) wrote:
> Geoff,
> Thanks for the detailed explaination - it does make a lot of sense..
> As you've pointed out in case of SHMHT, if a server is lightly loaded, the
> session id will be cached for a time greater than the expiry time - but a
> session is NOT resumed based on this session-id. So, I guess it's still
> okay. I also fully understand your views of shmcb and dbm methods of
> caching.
I'm not sure you got the seriousness of the shmht situation. The problem is
not light loads, it's high loads. There is a global (although I assume
per-process) time_t value that is stamped each time *real* expiry logic is
performed. All other "expire" attempts in future will silently return
without any action until SSLSessionCacheTimeout seconds have passed since
that time_t timestamp ... the first "expire" function call after that
interval has passed will do real expiry processing and will reset the
time_t value.
So the problem is this - if you negotiate a new session *just* after a real
expiry operation has taken place ... then in all likelihood, the next real
expiry will take place just before your session is due to expire. So it
won't be removed. However, it will "expire" just after the expire operation
has taken place, and so will sit there until the next real expiry - despite
the fact that is spends most of that interval "stale" (can't and won't be
resumed). This poses a storage problem - its presence can still stop new
sessions being cached even though it is old and wasting space. When you
have a cache under high-load (ie. where the cache is kept full) then we'd
expect mathematically for 67% of the cache to hold sessions that aren't too
old, and 33% to hold sessions that are old and wasting space.
This would be OK if inserts always succeeded by flushing out the oldest
available session - but shmht's internal design makes that infeasible (the
reason a time_t timestamp is used to prevent real expiry handling happening
too often is that the expiry logic in shmht is necessarily a very expensive
operation). It's why shmcb was written - real expiry logic is trivially
fast so happens all the time (rather than "faking" it and only doing real
work every "Timeout" seconds). That and the "insert always works"
properties were the main motivations for it.
> Anyway, your point is well taken. I guess it's a issue of security vs
> performance - and I'm sure security takes a upper hand.
Simplicity is probably the key word in all this. :-)
Cheers,
Geoff
______________________________________________________________________
Apache Interface to OpenSSL (mod_ssl) www.modssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
