[198] in Zephyr Mailing List

home help back first fref pref prev next nref lref last post

Re: zephyr at MIT using Kerb5

daemon@ATHENA.MIT.EDU (Derek Atkins)
Tue Dec 19 13:33:29 1995

To: Ed Hurley <hurley@mama-bear.lcs.mit.edu>
Cc: 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:31:28 EST
From: Derek Atkins <warlord@MIT.EDU>

> this sounds (to me) like a shortcoming in the original zephyr design.

Yes, it is.  In fact, most of the zephyr hackers today would
completely agree with you.  The zephyr protocol has a bunch of
problems, this is one of them.

> if so, i have two questions:
> 
> 1. what, if anything, will be changed in future zephyr releases to correct
>    this?

Probably nothing.  To change this would require changing the whole
zephyr protocol, which would make it completely incompatible with
current zephyr applications.  I doubt that the protocol will be changed
this drastically in version 2.1.  Perhaps zephyr 3 (if it ever happens)
might change this.

> 2. ideally, what *should* be changed...

Ideally, zephyr should be redesigned.  knowing what we know now about
how zephyr is used, it should be redesigned from the ground up.  The
protocol should be made into a binary protocol (8-bit clean), realms
should be properly defined, inter-realms should work cleanly and be
relatively invisible to the user.

Also, the protocol should be bi-directional rather that the triangle
pattern that currently exists.  For example, zwgc talks to zhm which
talks to zserver.  Acks return using the same path, but the zserver
finds out where the zwgc is and talks (later) directly to zwgc.  This
forms the triangle.

I'm sure other changes _should_ be made, but this requires a complete
protocol redesign, which I dont think anyone is going to do in the
near future.  But don't take my word for it -- I don't work for MIT.

-derek

home help back first fref pref prev next nref lref last post