[69] in Zephyr Mailing List
Re: Fixing the Zephyr daemon
daemon@ATHENA.MIT.EDU (raeburn@cygnus.com)
Tue Jun 2 22:41:23 1992
Date: Tue, 2 Jun 92 22:38:47 EDT
From: raeburn@cygnus.com
To: dpk@fid.Morgan.COM
Cc: zephyr@Athena.MIT.EDU, technology@gateway.morgan.com
In-Reply-To: <9206022344.AA03918@Morgan.COM> (dpk@fid.Morgan.COM)
I think you may be facing more problems than you realize, in the situation
you're describing:
* If your long-haul network is relatively slow, you should change the
handling of timeouts -- at least change the numbers. You did mention
maintaining full connectivity, but that isn't the case for the networks I
deal with daily. Handling temporary outages semi-gracefully should be a
requirement.
* If you have a lot of people at each site, the inter-server traffic will
be large.
* Each server must maintain the entire database for all sites in memory;
none of it is maintained on disk. From my experience at MIT, I'd say the
database should fit in memory without swapping; otherwise, you'd better
have very fast disks.
* Messages to multiple recipients at distant sites (either as a list of
recipients, or subscribers to a <class,instance,*> tuple) may cause lots
of intercontinental traffic for each message, when the fanout could be
handled at the remote end.
* Some serious bugs exist in the brain-dump code, but I'm fuzzy on the
details. I fixed some, and MIT may have fixed more since then.
* Are you using Kerberos?
* If so:
* How are you getting Kerberos into France? I understood they had
restrictions on import of cryptographic software. (The US has
export restrictions too, which Cygnus is fighting, but I think some
sites outside the US might have a re-integrated version available.)
* Are you using one Kerberos realm for all clusters, or several
realms? If you're using multiple realms, I think some Zephyr code
may need patching up to handle multiple Kerberos realms. I don't
think the patches (if any are indeed required) are significant.
* If not, reconsider. :-) The Zephyr user programs don't use setuid
privileges to give any sort of so-called "authentication". So anyone
could get your messages, and could fake messages from any of your
users.
As you can probably tell, I've talked with people about some of these
problems (though it's been a while). Not working at MIT any more, I can't
make any statement about what they're going to do, but I know many people
(some outside MIT) who are interested in getting the protocol (and
attendant code) rewritten to handle some of the above problems.
Making the server multi-threaded is just an obvious part of reimplementing
it for a new protocol. It could be done for the current one, but I
suspect that might not be sufficient.
If you think it would be enough, talk to people at MIT about getting a
copy of the current code. I did some work on it while I was there, and
had it working with three and occasionally four servers. (They are only
using two now, so I assume either some bugs remained that I didn't
encounter, or their conversion of the C++ code to C introduced some.) It
might be useable, and it's long past time to get a new version out, which
I failed to do while I was there....
Ken
