Path: utzoo!attcan!uunet!zaphod.mps.ohio-state.edu!mips!twg.com!david From: david@twg.com (David S. Herron) Newsgroups: comp.mail.uucp Subject: Re: V.32 vs. PEP for lots of small uucp transfers Message-ID: <8263@gollum.twg.com> Date: 11 Nov 90 05:53:10 GMT References: <6937@sugar.hackercorp.com> <406@aupair.cs.athabascau.ca> Reply-To: david@twg.com (David S. Herron) Organization: The Wollongong Group, Palo Alto, CA Lines: 55 In article <406@aupair.cs.athabascau.ca> lyndon@cs.athabascau.ca (Lyndon Nerenberg) writes: >karl@sugar.hackercorp.com (Karl Lehenbauer) writes: >Something else to look at is running batched SMTP instead of individual >rmail jobs. This has the advantage of working with PEP only modems, and >gives you even better throughput than running lots of small jobs through >V.32, since it practically eliminates file-complete handshake sequence. Yes, that and the fact that you get to use real RFC-822 mail without all those groady & uncertain translations to UUCP/RFC-976 format. (Remember the perenniel argument on Rabid ReRouting? It becomes a lot simpler if you're using absolute domain names ...) >Of course, both you and your neighbour must be running an MTA that supports >this. Smail3 handles this in a very straight forward manner. I'm not sure >if there are any other MTA's that do this right now. It could be added to >sendmail without too much work. Ahem .. at least the incoming portion is available already in comp.sources.unix archives everywhere. Even though I have religious difficulties with sendmail I made this program work with both sendmail & MMDF... It does assume that you have a real mail system ... I have some patches in my mailbox which I'll get to eventually and there'll be a new version popping out sometime in the next few months. Promise ;-) The problem is correctly doing outgoing batching ... You really want to make sure that there's some number of messages inside the UUCP batch file. In MMDF what I would do is only run the deliver daemon infrequently -- and assumably this will usually give me UUCP jobs with multiple messages. But this isn't certain to batch multiple messages, and also if the neighbor polls at the wrong time then they'll miss picking up messages .. So it would be good to push the message into the UUCP queues as soon as possible after it arrives. Which is counter waiting awhile so that you can be more sure of having multiple files batched up. One solution I know of, I didn't think of it -- the guys who are/were at SanDiego.NCR.COM did (yes, I'm talking about you guys again) -- is to keep track of the current UUCP job which has batched messages in it. Then "know" how to translate the UUCP job number into a file name in /usr/spool/uucp. Then append the next incoming message to that file. Groady & low-level but it works. Oh, it's not a simple append since you have to back up prior to the "\r\nQUIT\r\n" at the end of the file. A smallish improvement to that might be to treat QUIT as an RSET, so that you can use a simple append & maybe save a bit of ugly code. -- <- David Herron, an MMDF & WIN/MHS guy, <- Formerly: David Herron -- NonResident E-Mail Hack <- <- Use the force Wes!