Path: utzoo!attcan!lsuc!eci386!clewis From: clewis@eci386.uucp (Chris Lewis) Newsgroups: comp.dcom.modems Subject: Re: MNP vs. uucp 'g' - my solution Message-ID: <1989Sep27.211826.17398@eci386.uucp> Date: 27 Sep 89 21:18:26 GMT References: <125285@sun.Eng.Sun.COM> Reply-To: clewis@eci386.UUCP (Chris Lewis) Organization: R. H. Lathwell Associates: Elegant Communications, Inc. Lines: 39 In article <125285@sun.Eng.Sun.COM> shannon%datsun@Sun.COM (Bill Shannon) writes: >As "everyone knows", MNP and uucp's 'g' protocol just don't get along. >So, I decided there must be a better way. What does MNP give you? >MNP 5 gives you reliable data transfer (at least from modem to modem >if not from program to program) and data compression.... >So, what I ended up doing is writing a new uucp protocol based on >the 'g' protocol but including automatic compression of the data. >I call the new protocol 'c'. From the point of view of processor performance, why didn't you simply use (or implement) "f" protocol? Then you could use MNP compression without using any host overhead, and not worry about end-to-end-to-end ACK delays? Not to mention being able to talk to other "f" implementations (eg: stock 4.3 BSD UUCP). Having checksumming ACK's is only of interest when the end-to-end link isn't error free, so if you do have error correction and reliable host-modem links (eg: working hardware flow control), why bother? (except of course for a single one at the end of each file, or perhaps every (baud-dependent) number of kilobytes/number of transmission seconds.). T'would even work if you had to multi-hop thru X.25 lines (ie: telenet supported dialup MNP modems). And, of course, you could *greatly* speed "f" up by eliminating the 7-bit bashing for binary files. I have a tendency to think that UUCP protocol should vary *only* to take into account transmission medium, not additional bells and whistles. As another has pointed out, encryption/compression should really be another layer. Having uucico *automatically* invoke [en|de]cryption and/or [de]compression *prior* to sending or *post* receiving sounds like a better idea than yet another transport protocol. A brute force mechanism would be for uucico to automatically compress anything going outwards, and detecting ".Z" suffixes and attempting to decompress on incoming. -- He's a consultant: | Chris Lewis, Elegant Communications Inc. Lend him your watch | UUCP {uunet!attcan,utzoo}!lsuc!eci386!clewis and he'll tell you the time. | Moderator of the Ferret mailing list. Don Munroe, Cosmic Commander|