> 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. 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.
What about the following scheme: if an already existing session
is to be added to the session chache then the session in the
cache is marked as unresumable, kind of attaching a "dirty tag".
Thus even the original client needs to do a full negotiation.
Of course, this does not help with inconsistencies to other
local chaches..
--
Holger Reif Tel.: +49 361 74707-0
Smarttrust GmbH Fax.: +49 361 7470720
Europaplatz 5 [EMAIL PROTECTED]
D-99091 Erfurt WWW.SmartTrust.com
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
