In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Ken Raeburn) wrote: > On Oct 4, 2004, at 01:40, Frank Cusack wrote: > > > Heimdal does not have a functioning replay cache, so if your app > > needs that you must go with MIT. > > > If heimdal is thread-safe, that's news to me. You shouldn't care > > if the apps you plan to use are off the shelf (sounds that way). > > MIT's use of a replay cache also leads to poorer performance of > application servers under very heavy load (but if you're not under > heavy load, do you care about that extra tiny fraction of a second > delay?). I believe the replay cache may also be a contributor to MIT's > reported worse behavior in multithreaded servers; none of that code is > thread-safe, and we can spend quite a few cycles there.
That fits with my observations with Cyrus SASL GSSAPI authentication in an LDAP service. Heimdal is commonly recommended there. I tried both, and MIT was indeed slower and crashed in the GSSAPI code under heavy load. But it's really pretty simple to add an interlock to the SASL GSSAPI module, which disposes of the issue entirely, and I felt that authentication was acceptably fast and we didn't need to abandon replay checking. Donn Cave, [EMAIL PROTECTED] ________________________________________________ Kerberos mailing list [EMAIL PROTECTED] https://mailman.mit.edu/mailman/listinfo/kerberos
