[1371] in Kerberos_V5_Development
Re: kdc performance and rcache
daemon@ATHENA.MIT.EDU (Theodore Y. Ts'o)
Wed Jul 3 00:06:56 1996
Date: Wed, 3 Jul 1996 00:06:44 -0400
From: "Theodore Y. Ts'o" <tytso@MIT.EDU>
To: Ken Raeburn <raeburn@cygnus.com>
Cc: "Donald T. Davis" <don@cam.ov.com>, "Barry Jaspan"
<bjaspan@MIT.EDU>,
krbdev@MIT.EDU
In-Reply-To: Ken Raeburn's message of 28 Jun 1996 20:25:49 -0400,
<tx1d92jzcaa.fsf@cygnus.com>
From: Ken Raeburn <raeburn@cygnus.com>
Date: 28 Jun 1996 20:25:49 -0400
However, there's no asn1 context in which to put a cache... How would
people feel about my creating one, pointed to by the asn1buf, and
passed into asn1buf_create? Then the KDC can have optimal time
conversion, and the library code is still thread-safe. (Well, as much
as it is now.)
Unless the asn1 context is ultimately linked to the krb5 context (as
opposed to being stored in a static variable), I don't see how it would
be thread-safe --- or was that what you were planning to do?
On a related note, I noticed about 20-25% of the time conversions had
the value 0 (Jan 1 1970), coming from a "last-req" field. Does this
sound reasonable??
The code is currently encoding the last-req field as a one element array
(sequence of) where the lr_type is LR_NONE, and the lr-value is
ignorable. ASN.1, however, should allow us to encode a zero-length
array, which would not violate the protocol spec, but it would save us
some 10-20 bytes in the ticket, and avoid needing to encode the date one
more time.
The only question is whether making this change would cause existing
implementations to core dump, but my guess is it's very likely we can
change what the KDC encodes in the last-req field without any problems.
- Ted
