[2655] in Kerberos_V5_Development
Re: Kerberos NT source code
daemon@ATHENA.MIT.EDU (Christopher Blizzard)
Fri Oct 24 15:41:45 1997
To: "Theodore Y. Ts'o" <tytso@MIT.EDU>
Cc: Assar Westerlund <assar@sics.se>, Sam Hartman <hartmans@mesas.com>,
Ezra Peisach <epeisach@MIT.EDU>, Ken Hornstein <kenh@cmf.nrl.navy.mil>,
krbdev@MIT.EDU
In-Reply-To: Your message of "Fri, 24 Oct 1997 09:49:32 EDT."
<199710241349.JAA26848@dcl.MIT.EDU>
Date: Fri, 24 Oct 1997 15:40:55 -0400
From: Christopher Blizzard <blizzard@AppliedTheory.com>
In message <199710241349.JAA26848@dcl.MIT.EDU>, "Theodore Y. Ts'o" is rumored t
o have said:
:
:For example, if you're using threads to handle your GUI for a client
:application, there's probably not much we need to do at all. If you're
:using threads for a server application, it would be useful to note how
:people are divvying up the work, and why. (For example, why call
:krb5_rd_req in the listener thread, instead of in the worker thread?
:Are you going to have one thread per connection? Etc.)
:
: - Ted
:
Where I work, most of our work with threads is with server applications.
There are a lot of reasons why using threads is more attractive, the most
important of which are performance and portability.
On the downside, locking issues are a problem with any situation where
multiple applications may be accessing a specific resource, including
multiple threads within the same application. Personally, I think that
clearly stating what parts of the Kerberos V api are potentially un-thread
safe is enough. I'm just worried about globals hanging out in the
encryption code which is used by many of the other parts of the Kerberos V
api.
I have to admit that I haven't even looked at the api for Kerberos yet
because I haven't had the need, but I do want to start using it in
applications because from a conceptual standpoint it solves a lot of
security problems that we have to deal with with our applications.
One of the requirements for "3rd party" api's and libraries for our use is
that they are thread safe, but don't necessarily force you to use a
threaded model. Right now, aside from global locks around all parts of
the Kerberos V api, which would really hurt performance on threaded
servers, we can't incorporate the MIT Kerberos libraries into our
applications.
I don't know if this has been one of the goals of the MIT project or not,
that is to be viable in a commercial environment, or if it exists only as
a reference implementation.
Comments?
--Chris
------------
Christopher Blizzard
AppliedTheory Communications, Inc.
http://odin.appliedtheory.com/
blizzard@appliedtheory.com
------------
