httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Darroch <>
Subject Re: RFC: extracting the mod_ssl session cache interface
Date Tue, 26 Feb 2008 22:06:05 GMT
Joe Orton wrote:

> Is there any interest in seeing this extracted from mod_ssl and made 
> available for general use?  It could probably e.g. be used by 
> mod_auth_digest for the MD5-sess code, and I can think of some 
> third-party modules which could probably use it too (mod_gnutls).
> My vague plan would be to finish de-SSL-ifying the code, then moving it 
> to modules/cache and calling it mod_sesscache or mod_socache ("small 
> object") or something along those lines.

   Definitely +1 from me.  If you don't mind, please have a glance
over my thoughts from last year on similar kinds of issues:

   At the bottom of all that I'd flagged mod_ssl and mod_auth_digest
as possible users of a generic cache mechanism, as well the scoreboard
and mod_proxy.

   Roughly what I'd envisioned was several "levels" of providers,
each of which must provide a small set of hash (atomic) and table
(possibly non-atomic) access functions.

   The intention of the table access functions is, primarily, that
these would fulfill the needs of the scoreboard: an integer-based table
of fixed-length records, which if stored in shared memory would be
updated non-atomically to ensure relatively quick access.  Essentially,
what the scoreboard does now, but re-factored.

   Leaving the scoreboard aside, most other potential users might
prefer the hash access functions; slower, but guaranteed to be
atomic.  I hadn't thought about the format of keys and values, but
since Paul Querna asked about it, I'd be inclined to suggest
perhaps strings or apr_datam_t for keys and apr_datum_t for values.
String keys allow for prefixes, as others suggested.

   I tried to describe some possible providers, with the "simpler"
ones being just wrappers around DBD or DBM or plain APR tables/hashes
(that last being only appropriate for single-process servers).

   The next step up -- shy of a whizz-bang distributed system
supporting multiple httpd servers -- would likely be the key provider
to implement first, one that used shared memory.  In some ways this is
the hardest, because of the issues around sizing the memory appropriately
and dealing with allocations within it.

   I proposed a few notions about how such a provider and its
users might interact, with the provider indicating it could not
support resizing, users (i.e., modules) indicating their requirements,
and the server coordinating with the provider at startup and restart
time to request one large block and then handling out hashes and
tables to the various users.

   Resizing the allocated shared memory when restarting (for example,
because a module has been added to the server configs, or some directives
were changed) is pretty unpleasant.  The scoreboard currently just dodges
the problem by sizing only at startup, from compile-time maximums.  At
the bottom of my notes there are some ramblings about how one might
reference count the allocations from previous server generations and
deallocate them when all child processes of that generated had exited;
I can see this might prove unworkable in real life, though.

   For many non-shared-memory based providers like DBM, DBD, plain APR,
or some external cache (memcache, etc.), resizing should be trivial,
of course.

   I happen to have some breathing room coming up in between other
things and would be keen to toss around some ideas and/or code.
I'm open to suggestions on how best to proceed.  Maybe some
mocked-up header files to discuss function prototypes?  Some stub
code in amsterdam or elsewhere?  Further discussion?  Please feel
free to add/amend/flame my notes in that scoreboard.txt file!


GPG Key ID: 366A375B
GPG Key Fingerprint: 485E 5041 17E1 E2BB C263  E4DE C8E3 FA36 366A 375B

View raw message