Proposed modifications to replay cache to prevent false positives

[Nicolas Williams]

On Tue, May 20, 2008 at 06:33:13PM -0400, Ken Raeburn wrote:
> On May 20, 2008, at 16:16, Nicolas Williams wrote:
> >B-trees won't help that much, and may possibly hurt.  Unless...
> 
> I think part of the intent in this project was to retain backwards  
> compatibility with the existing implementation in terms of the on-disk  
> format.  ...

Yes, I know, but since B-trees were mentioned I thought I'd point out
what needs to be done to make B-trees helpful, perf-wise, rather than
hurtful.

> >Will F. greatly improved the performance of the replay cache on  
> >Solaris.
> 
> Not surprising; our code is horribly inefficient at doing the i/o, at  
> the very least.  (I think we've also got race conditions between  
> processes.)  And we could probably do something more clever with the  
> in-memory version than a fixed-size hash table with a lame hash  
> function.  It may also be worthwhile distinguishing and optimizing two  
> different cases, the short-lived server that handles only one client  
> and then exits (e.g., telnetd), versus the long-lived server that  
> handles a large number of clients (e.g., slapd).

Will profiled the code and found unnecessary gettimeofday() syscalls in
the main loop and function calls in the main loop which when turned to
macros greatly reduce overhead.

> >- provide an option to set the server-side skew to some number of
> >  seconds, which in general should be estimated time to boot * 2
> 
> [libdefaults]->clockskew is used (and defaults to 300s)

Yes, yes.  I'd like that to be somewhat more automatic.  One boolean in
the config, instead of a numeric.

> >- provide an option to put the rcache on tmpfs or tmpfs-like
> >  filesystems
> 
> setenv KRB5RCACHEDIR /path/to/tmpfs
> (or TMPDIR)

Again, if you know you have clockskew set based on estimated time to
boot then you can just put the default location on tmpfs.  Of course,
that means knowing what that ought to be, but that can be a ./configure
option.

> >An rcache implementation as a daemon reached via IPC would be even
> >better.
> 
> Yes, we've discussed it, but that's a bit more work. :)

Yes, and if it must be portable...  On Solaris the best IPC for this is
doors, but that's not portable, sadly.

Nico
--