How to prevent very very large ccaches?

[Nicolas.Williams@ubsw.com]

Indeed, all those lseek()s and read()s sure look, well,
superfluous and inefficient.

For now it's clear that the lock/unlock for each ccache entry
sequenced causes ccaches not to scale beyond a fairly small
number of entries, N.

All those unnecessary lseek()s and read()s might mean there's
another knee in ccache sequencing for a much larger N, say,
50,000. I'm very happy to say that there are many fewer than
100,000 hosts for me to look after :) so that I don't (yet)
care about any possible knee in searching such large ccaches.
For now the OPENCLOSE fix should result in an improvement of
at least an order of magnitude when doing massive, parallel
ssh/krsh to thousands of hosts.

Note to future ccache implementors: one thing I take away
from the way I use Kerberos is that ccache searches are more
common than ccache insertions, but both must be fast enough
as to not be noticeable; O(1) insertion and lookups would be
nice, but I'd settle for O(ln(N)) :)

Cheers,

Nico
--  

> -----Original Message-----
> From: Ken Hornstein [mailto:kenh at cmf.nrl.navy.mil]
> Sent: Tuesday, June 18, 2002 6:41 PM
> To: kerberos at mit.edu
> Subject: Re: How to prevent very very large ccaches? 
> 
> 
> >Wow.  I knew we had some bogus stuff in some of our I/O code, but
> >didn't realize it was so serious.
> 
> There's a bunch of stuff in there.  I noticed during a system 
> call trace
> once that keytabs are apparantly read in a byte at a time.  I haven't
> tracked that one down yet, though (it might be fixed in newer versions
> of Kerberos, so I haven't made a big deal about it).
> 
> --Ken
> ________________________________________________
> Kerberos mailing list           Kerberos at mit.edu
> http://mailman.mit.edu/mailman/listinfo/kerberos
> 

Visit our website at http://www.ubswarburg.com

This message contains confidential information and is intended only 
for the individual named.  If you are not the named addressee you 
should not disseminate, distribute or copy this e-mail.  Please 
notify the sender immediately by e-mail if you have received this 
e-mail by mistake and delete this e-mail from your system.

E-mail transmission cannot be guaranteed to be secure or error-free 
as information could be intercepted, corrupted, lost, destroyed, 
arrive late or incomplete, or contain viruses.  The sender therefore 
does not accept liability for any errors or omissions in the contents 
of this message which arise as a result of e-mail transmission.  If 
verification is required please request a hard-copy version.  This 
message is provided for informational purposes and should not be 
construed as a solicitation or offer to buy or sell any securities or 
related financial instruments.