[ANNOUNCE] Distcache 0.3 released

Hi all,

I'd like to announce the release of version 0.3 of distcache, a toolkit
for distributed session caching. This is the first release I consider
ready for general use - we've upgraded the status from pre-alpha to
alpha, though in reality I think it's more like a beta minus various
packaging extras that would be needed for a normal beta release. In other
words, it should be solid - but until it gets some testing in different
environments and configurations, we won't bet the house on it. Yet.

The home page is at;
http://www.distcache.org/

There is a support package for integration with mod_ssl (2.8.12) and
another for integration with Apache 2 (2.0.44). I am hoping to find time
to coax this integration into a form that could be integrated into
mainstream releases (right now, if you apply the patches you get
distcache support whether you want it or not :-)

The rest of this note contains some information on what distcache is and
what it can do. It's (more or less) the same info I'm sending to other
relevant mail lists too, and you can stop reading if you are not
interested in distcache at all or if you are interested but intend to
download the code and view the README.

So, quick basics: distcache exists to provide a session cache and a
light-weight async network protocol (+ wrapper library and utils) for
manipulating caches. The typical configuration has a session cache server
listening on an arbitrary machine, eg. listening on an IPv4 port;

dc_server -daemon -listen IP:9001

or just one IPv4 interface;

dc_server -daemon -listen IP:192.168.0.1:9001

or on a unix domain socket (for single-machine setups);

dc_server -daemon -listen UNIX:/tmp/name-your-socket

Client programs (apache, stunnel, whatever) can communicate directly with
the server if desired, but the protocol has been built with the idea of
local agents performing their work for them - this typically improves
scalability and allows client programs to be a little more robust by
opening temporary unix domain connections to the agent rather than the
large overheads (and TIME_WAIT bloatage) of connecting over IPv4. This is
also far easier than having applications try to intelligently manage
connection pools, etc. Eg. a machine hosting an SSL/TLS server
application would start an agent via;

dc_client -daemon -listen UNIX:/tmp/dc_client \
-server IP:192.168.0.1:9001

Each agent holds open a single persistent connection with the dc_server
instance, and any and all application connections to dc_client are
multiplexed back and forth through the persistent connection. dc_client
is quite robust in the event of network errors, and will periodically
attempt to re-connect with the server as/when it loses connectivity.
Caching operations will "fail" gracefully during such downtimes but will
automatically start functioning properly again when communications are
re-established. This is configurable behaviour.

Likewise for the client API used for making OpenSSL-based applications
distcache-aware, the context creation specifies the address of the
dc_client (or dc_server) instance - if the required utilities are not
running or are experiencing network problems, caching will silently fail
in the application (ie. session-resumes fail and become full handshakes,
no caching of negotiated sessions, etc) but will start functioning again
as/when the cache tools and the network is up and running.

Finally, the protocol is extremely lightweight - I have regularly pushed
15,000 cache operations per second through a modest desktop test, and the
network protocol itself is thin enough that is it dominated by the size
of session data it carries which itself is also quite small (eg. approx
128 bytes for a standard SSL/TLS session serialised by OpenSSL, or ~1Kb
when the server requires client certificate authentication). A 10Mbit
link can easily sustain enough distcache traffic to satisfy an enormously
high-load SSL/TLS cluster (which we can safely assume would be using
something better than 10Mbit ethernet :-), and likewise the overhead of
the tools even at those enormous volumes are minimal on the system. So,
your application (and OpenSSL's SSL/TLS implementation) will remain the
limiting factor and it would highly surprising if you could find any
difference at all w.r.t. latency or overhead by using distcache. The
benefit on the other hand is that different machines can transparently
resume sessions negotiated by each other - thus making the scalability
and load-balancing semantics of your server network more flexible.

Enough already. Any/all feedback is most welcome.

Regards,
Geoff

--
Geoff Thorpe
geoff@geoffthorpe.net
http://www.geoffthorpe.net/


____________________________________________________________ __________
Apache Interface to OpenSSL (mod_ssl) www.modssl.org
User Support Mailing List modssl-users@modssl.org
Automated List Manager majordomo@modssl.org