Performance and Replay Cache
se10 at cornell.edu
Thu Dec 7 10:21:14 EST 2006
In the early 90s, a basic client/server protocol was developed at
Cornell called Cornell University Stateless Server Protocol (CUSSP).
Each request from the client contains a K4 ticket for
authentication. The contents of each request are encrypted with
This protocol is still used on a few servers. One of these servers
commonly sees an incoming request rate of 35 requests per second.
After converting CUSSP to use K5, the increase in latency resulting
from the replay cache affects performance.
If the replay cache is not used, K5 latency is low; about that of K4
latency. A search on the krbdev mail list archives mentions some
applications do not need the replay cache, but I think ours needs the
replay cache. Can someone comment on under which circumstances the
replay cache need not be used?
Also from reading previous posts, I noticed some folks have mentioned
the possibility of using a memory based replay cache as opposed to a
disk based replay cache. The risk with that being no replay cache is
available immediately after a server restart. Has anyone used a
memory based replay cache, and if so did you see a big increase in
Is a significant increase in performance for a disk based replay
cache possible via an alternative implementation? That is, could
changes or optimizations to that code improve its speed? If so, we
may have someone here at Cornell who could investigate and contribute.
More information about the krbdev