[199] in Zephyr Mailing List
Re: zephyr at MIT using Kerb5
daemon@ATHENA.MIT.EDU (Greg Hudson)
Tue Dec 19 13:38:56 1995
To: Ed Hurley <hurley@mama-bear.lcs.mit.edu>
Cc: Derek Atkins <warlord@MIT.EDU>, zephyr@MIT.EDU
In-Reply-To: Your message of "Tue, 19 Dec 1995 13:07:44 EST."
<9512191807.AA10186@arctos.LCS.MIT.EDU.LCS.MIT.EDU>
Date: Tue, 19 Dec 1995 13:36:42 EST
From: Greg Hudson <ghudson@MIT.EDU>
> 1. what, if anything, will be changed in future zephyr releases to
> correct this?
Since I expect most of my work time to be eaten up by release
engineering, one priority is going to be "requiring little development
effort."
I will probably move to binary encodings in 2.1, since I need to make
incompatible protocol changes anyway.
> 2. ideally, what *should* be changed...
Zephyr should have been a stream protocol, like NNTP or SMTP. If TCP
is undesirable because of the kernel resources required (in
particular, the need for keeping unacked packets in kernel space),
then a stream protocol should have been designed on top of UDP.
The current packet protocol may allow slightly better server
performance and therefore may have saved some hardware costs, but it
has resulted in far more expense in terms of developer time and lost
outside development effort (that is, probably fewer non-MIT people are
willing to work on the code because it's so difficult to understand).
Once you have a stream protocol, you can authenticate once at the
beginning of the connection and use a stream cipher from then on.
Of course, it's not clear to me that the packet protocol allows better
performance. The Zephyr servers spend the majority of their time
inside the kernel receiving and sending packets, and in the current
packet protocol you can only do one thing per packet. With a stream
protocol, I could potentially get locations and subscriptions in the
same packet, send a short message to ten different individuals in just
two or three packets even if the server doesn't support multiple
recipients, etc..
A stream-based protocol is also much more amenable to a multithreaded
server, and thus to an implementation which can use multiple CPUs.
I think it would only take a few months of my free time to hack up the
beginnings of a Zephyr clone with such a design if I got to use
threads. I have too many other projects eating my free time in the
indefinite future, though.
