From: utzoo!decvax!harpo!duke!mcnc!unc!smb Newsgroups: net.followup Title: Re: CSNet opinions? Article-I.D.: unc.3638 Posted: Wed Jun 30 15:59:40 1982 Received: Thu Jul 1 06:28:41 1982 References: iuvax.116 (Very long note....) We're on CSnet, and will soon (about 2 weeks) switch over to it as our standard mail system. Before I comment further, though, I should explain what MMDF is. MMDF stands for "Multi-channel Memo Distribution Facility". It was developed by Dave Crocker at the University of Delaware as part of the CSnet project (more on CSnet below). MMDF proper is really a replacement for delivermail -- the program that takes a formatted letter, and sends it out on some network. It is possible (I've done it) to use standard Berkeley mail as your composing/reading tool but have MMDF deliver the mail. MMDF uses the standard ARPA addressing format -- user@host -- and will very likely track changes needed for the new Internet addressing standard. Once MMDF gets the letter, it verifies the addresses, expands aliases, and decides what to do with it. Rather than use the network delimiter ('!', '@', or anything else) the way delivermail does, it searches a host table associated with each channel, and queues the message accordingly. The message is then picked up by a channel module (either immediately or in the background, depending on assorted configuration options); the channel module attempts to deliver it. The latest release from Delaware supplies three channels: a local delivery channel (handled by /bin/mail in the Berkeley system), an ARPAnet channel (more on that below), and a PhoneNet channel. This latter is the component that most resembles uucp; it passes messages over a tty connection. (Technically, the phone channel is two different channels, an active module that makes calls, and a passive one that receives them.) Doug Kingston at BRL (unc!brl-bmd!dpk) has written a uucp channel; it takes a queued MMDF message, mungs the header a little bit, and invokes uux to send it off someplace. (Advt. -- my pathalias program can generate the proper host table, including all routing information, for the uucp channel.) I've modifed the ARPA channel (slash/hack) to talk over our local net here; my code could easily be modified to use any local net. There will soon be an SMTP channel (SMTP is the new ARPAnet mail transfer protocol). Etc. What does it all mean? Well, the channel concept means that users don't have to worry about routing and configuration. Currently, we use the uucp channel to send letters to brl-bmd and duke, because that's how the bulk of our traffic is going. If I were to change the channel tables, letters would go via PhoneNet, and no one would notice. Currently, the relay machine at Delaware polls both UNC and Duke to pick up CSnet-bound mail; it would be trivial to change tables so that Delaware called only one machine, which would do relaying for the other. Again, users wouldn't notice any change. Configuration with MMDF is a bit harder than with uucp, except for the very simplest cases -- channels can do much more, so they need more attention, especially at first. And the documentation is a bit sketchy. Complex configurations can be very tricky; I've been working with this stuff for months, and stumbled across (was hit over the head by...) a very serious channel configuration bug just last night. And a relay machine that polls many others will have a tough time keeping things current; too much is compiled in. (One nice touch, though, is a program that verifies the existence and mode of the component files, programs, directories, etc.) MMDF was designed from the start to be more robust and more secure than uucp (not that that says much....). Outbound messages are stored below a mode 700 directory, which means you can't even tell how many messages are queued without a privileged program to help you. It's much harder to fake messages than with uucp. It warns you after two days when it can't deliver a message; if it finally gives up, it mails the original back to you. Uucp often acts like a black hole.... Reliability and availability of the CSnet relay machine has been fairly good on the average; most of the time, it's excellent, but there have been a few outages of several days each. Some of these have been hardware problems; others have been caused by bugs in the MMDF software. The most vulnerable point is that channels operate sequentially on all messages in their queue; if there's one message that hangs or somehow blocks things, the entire channel (and perhaps channels below it in the priority scheme, depending on configuration) will be blocked. There's been some talk of flagging troublesome messages, and giving up on them after a while. (Uucp is also vulnerable to this, of course.) The PhoneNet protocol seems somewhat less robust than uucp's packet protocol; I've noticed more line drops than seem appropriate, though some of that is apparently hardware flakiness. The higher-level part is better able to handle large files. I think that its line utilization is a bit lower than uucp's, though I'm not certain of that; however, if you're sending a letter to several people at the same site, it will only transmit it once -- a big advantage. The code quality is fairly good, and very modular -- perhaps too much so; until you get a feeling for the overall structure, it's a bit hard to follow all the jumping around. Similar modules -- the different channels, for example -- are structured identically; thus, if one channel needs a session initialization entry point, *all* channels will have one, even though it's null. The code is copiously instrumented; with debugging turned on, one can get an excellent trace of where things are dying. (The configuration bug I mentioned above had me stumped till I looked at the log data. Even without debugging turned on, one glance at it narrowed down the problem to two lines of code. Then my only problem was to figure out why they were failing....) CSnet is another issue entirely, though it's somewhat bound up with MMDF. CSnet is an NSF-funded project to link together computer science departments and industrial research labs across the country (I don't know about Canada); the relay machine at Delaware polls the PhoneNet sites, picks up outbound mail, and delivers inbound messages. (When trt, swd, jte, and I planned the first implementation of netnews, we figured we'd give away the software, and assumed that the traffic would be light enough that individual sites could pick up their share of the phone costs. The CSnet folks applied for a grant, and got a few VAXes, phone money, etc., from NSF. Professors do know a few techniques that graduate students should learn....) The link to ARPA through Delaware is officially blessed, so we don't have to worry about political problems at gateway machines. Because there's one main relay machine, it's easier to keep track of delivery problems -- if a message isn't received but has been picked up, it's got to be at Delaware. Uucp could do this also if we had one master site relaying everything, but Usenet is far larger (and far more anarchic) than CSnet is right now. Conclusion (at long last): we've obviously made our choice, since we are switching. CSnet access is definitely worthwhile, and if you want that, you have to take MMDF. Quite apart from that, I think that its robustness and its reconfigurability make it superior to delivermail; given BRL's uucp channel and my version of ucbmail, you lose nothing in flexibility or in ability to talk to all your friends on the Usenet. (If we had sendmail, the choice would be harder; sendmail (Berkeley's replacement for delivermail) is much more flexible than its predecessor, and easier to customize than MMDF is.)