On Thu, Feb 22, 2001 at 06:41:32AM -0800, Geoff Thorpe wrote:
[...]
> However, the problem remains that if external session caching is being used,
> even if the race in the "local" cache is resolved, the same race needs to
> resolved in the external cache which is less trivial. There would need to be an
> atomic operation that simultaneously checks if the session ID is unique *and*
> adds it to the cache if it is. Actually it's worse than that - the point at
> which we check for uniqueness of the session ID is too early in the handshake to
> have a session to put in the cache - so we're actually talking about reserving a
> session ID in the cache if it doesn't conflict.
Yes.
> Ugh. Trying to write this as a
> two-phase commit, (ie. first commit to the local cache, second commit to the
> external cache, with a rollback if necessary), together with getting the locks
> right for local cache operation as well as external cache operation (the latter,
> if it involves networking directly or via nfs, etc, can't be done inside a
> global lock, can it?), could be tricky.
Well, the session wouldn't be added to the local cache before we have
word from the external cache that it is unique. If there is an
external cache, its answers are considered authoritative, and some
subset of the contents of the external cache can be in the local
cache.
We have a problem, though, if the external cache decides to expire
sessions that have not yet expired according to the local cache. But
there's not much that we can do about this (except make session IDs
unique by using enough randomness) -- if there are multiple local
caches owned by different processes, then these processes necessarily
will have different world views.
--
Bodo Möller <[EMAIL PROTECTED]>
PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html
* TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt
* Tel. +49-6151-16-6628, Fax +49-6151-16-6036
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
