The rlm_cache module in master (what will become v3.1.x) has been rewritten internally to support drivers in a similar way to the rlm_sql module. The standard rlm_cache_rbtree driver is still present and works as it did before (I wrote tests to verify that). But there's also a new driver rlm_cache_memcached which integrates rlm_cache with memcached. Using a memcached allows cache state to be shared between multiple radius daemons. It also allows the cache to persist across restarts, which is useful if the cache is critical to the server's performance. The rewritten rlm_cache module behaves in a similar way as before, but with some minor differences in return codes (it will return OK instead of UPDATED, unless it copied a cached entry into the request). It also no longer merges the new cache entry by default, though that can be re-enabled with &control:Cache-Merge := 'yes'. The new behaviour is documented in mods-available/cache. Let me know if you feel any additional libmemcached knobs need exposing. Note: Because of the return code changes, the new cache code will not be merged into v3.0.x as it may break existing installations. --- Whilst investigating cache related things, I found a page on serializing the state of an SSL session in progress. This is potentially interesting for EAP as it would allow the EAP state to be shared between multiple clustered RADIUS servers (allowing for dumb load balancing, and failover). memcached certainly has the throughput to support being used in such a way ~200,000 TPS on untuned commodity hardware, so that might be an interesting thing to investigate in the future if people believe it would be useful. --- redis is another good candidate from a cache store, it's also persistent, so you may see a driver for that in the not too distant future as well. Sooner if there's significant interest. -Arran Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS development team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2