[263] in Zephyr Mailing List
Re: Making Zephyr a standard
daemon@ATHENA.MIT.EDU (Derrick J Brashear)
Thu Mar 6 13:55:03 1997
Date: Thu, 6 Mar 1997 13:45:42 -0500 (EST)
From: Derrick J Brashear <shadow@DEMENTIA.ORG>
Reply-To: Derrick J Brashear <shadow@DEMENTIA.ORG>
To: zephyr@MIT.EDU
In-Reply-To: <199703061820.NAA24153@the-light-fantastic.MIT.EDU>
> > I keep thinking to myself that it'd be nice to see a Zephyr
> > internet-draft or RFC, and eventually an Internet standard document
> > on it.
>
> Unfortunately, the Zephyr protocol is fundamentally flawed in multiple
> ways:
>
> * It uses a bogus encoding which multiplies the packet size by
> a factor of 3 or so.
This can be solved by bumping to 0.3 and just fixing it. It just means
compatibility problems.
> * It doesn't have any support for multiple authentication
> types, and the authentication scheme is uses is
> cryptographically flawed (des_quad_cksum() is not a good
> hash).
True.
> * It fails to establish a long-lived context for
> authentication, instead authenticating every packet the hard
> way (the server has some caching hacks to make this cheaper,
> but it's still a protocol flaw).
The problem with long-lived authentication contexts in a packet based protocol
is that if you're getting rid of some information, you're getting rid of some
information, which unless you're careful makes things less secure. A good
reference on this is the Hijacking Rx paper from CITI.
> * It uses a host-specific rendezvous point, enforced by the
> server, making it impossible for two people to use
> independent client implementations on the same machine.
Or be in different realms, with the "current" architecture.(*) Problem with a
simple change here is the server enforces the zhm port. I'm not sure why.
> * It has none of the TCP fairness algorithms (unless you count
> the exponential backoff I've added).
Well, it's not using TCP:-)
> * It is exceptionally inefficient at transmitting large
> messages, since it has no concept of windows and only
> acknowledges entire messages.
Presumably this is because the way it does it, while not terribly clean, was at
some point easy to implement. It's also a pain doing it this way if the packet
needs to grow at the server, like if (assume a multi-authentication-type
architecture) the receiving client has a different authentication scheme which
makes the packet too large. The server then needs to split the packet. Not
terribly hard, but a pain nonetheless.
> In my opinion, what makes Zephyr worth maintaining outside of MIT is
> zwgc, which has a fairly unique and hard to duplicate user interface
> in the world of messaging software. It's kind of amusing that I would
> come to this conclusion, since I personally don't even like
> windowgrams and use a custom interface which makes Zephyr look rather
> similar to IRC.
I keep having urges to extend zwgc to deal (somewhat) with MIME. So far I have
resisted. If I ever get the sparclinux midlevel audio support to work, maybe
I'll have to think about it more. Sigh.
-D
* Yes, I know about the zhm hacks which allow this not to be the case. zstat
johnstown.andrew.cmu.edu :-)
