[24880] in Kerberos
Re: context negotiation performance problem
daemon@ATHENA.MIT.EDU (Eric Mei)
Wed Nov 2 18:10:31 2005
Message-ID: <4369476A.3000205@clusterfs.com>
Date: Wed, 02 Nov 2005 16:10:34 -0700
From: Eric Mei <ericm@clusterfs.com>
MIME-Version: 1.0
To: kerberos@mit.edu
In-Reply-To: <08A35B0E-949B-4FA9-9550-78AABB051CA5@mit.edu>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
cc: Ken Raeburn <raeburn@mit.edu>
Errors-To: kerberos-bounces@mit.edu
Ken Raeburn wrote:
> That's almost certainly the replay cache file, meant to prevent the
> re-use of a transmitted authenticator by an attacker. The fsync is
> there to handle the problem of the machine crashing or losing power
> after an authenticator has been accepted and a data exchange
> performed, but the on-disk cache not yet updated.
>
> If your protocol or threat model is such that replay attacks are not
> a problem, then under later versions of the code (I'd check whether
> it's in the 1.4 series, but the machine where I keep my source trees
> checked out ate its root file system over the weekend) you could set
> the environment variable KRB5RCACHETYPE to "none" before starting the
> program. (Look for src/lib/krb5/rcache/rc_none.c to see if you've
> got the support.)
>
> Is this a single-process server, or multiple processes? Multiple
> processes would probably deal better with the fsync calls.
Thanks a lot Ken. 1.4.2 indeed support KRB5RCACHETYPE=none. I enable it
and rewrite the test as multi-processes. Now the server could handle at
least 600/s now.
Thanks again!
Eric
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
