Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!sri-spam!mordor!lll-lcc!ames!cit-vax!usc-oberon!castor.usc.edu!blarson From: blarson@castor.usc.edu.UUCP Newsgroups: comp.os.minix,comp.mail.uucp Subject: Re: uucp source copyright status - IMPORTANT Message-ID: <1414@castor.usc.edu> Date: Wed, 1-Apr-87 20:41:41 EST Article-I.D.: castor.1414 Posted: Wed Apr 1 20:41:41 1987 Date-Received: Sat, 4-Apr-87 19:43:22 EST References: <480@gouldsd.UUCP> <43183@beno.seismo.CSS.GOV> Reply-To: blarson@castor.usc.edu.UUCP (Bob Larson) Distribution: comp.os.minix Organization: USC AIS, Los Angeles Lines: 59 Keywords: uucp uucico kermit Xref: utgpu comp.os.minix:485 comp.mail.uucp:397 In article <122@njitsc1.UUCP> bc@njitsc1.UUCP (Bill Cheswick) writes: >In article <7319@boring.mcvax.cwi.nl> jack@boring.UUCP (Jack Jansen) writes: >>The point is, why should we use those icky uucp protocols that are >>hardly documented, and unused except in some proprietary sofware > >Because it is faster. Compare the transfer speeds of uucp and kermit: you only >get about half your baud rate in kermit file transfers. uucp does better. Kermit with full duplex windows should aproach 75% effeciency on binary files, and about 95% on ascii text files. UUCP will do worse than windowing kermit on lines with high latency. (Satelite links, fast "9600 baud" half-duplex modems.) (Kermit can work with up to 32 outstanding acks, UUCP is 2 I think.) The large packet option of kermit will do better than that in some situations. >Of course, the real problem is that kermit is still inefficient. The problem is kermit was designed for enviornments present in the real world, and UUCP for an ideal world. Many unix administators have trouble trying to get UUCP to work through real-world modems, port selectors, multiplexors, etc. > (They said >they were thinking of improving the protocol a couple of years ago. I wonder >if anyone has worked on it...) The extentions you are talking about are called "full-duplex windows" and "large packets". Both are present in the most recent protocol manual, and there are implementations available from Columbia university. Unfortunatly, neither are in the Unix implementation C-Kermit yet. Of course, all correct kermit implementations should work with all others, whether any specific enhancement is present or not. >And while you are looking for a protocol, how about using one that transmits >files in both directions at the same time? There are many protocols that >have solved this problem already. I've thought of proposing such an extension to kermit. >Actually, I use kermit quite often, and like it. But shouldn't a program >that may be responsible for a lot of telephone use be as efficient as possible? As efficient as practical. Squeezing a few percent more out a phone conversation by limiting yourself to a single vendor for software is a trade-off that should be examined closly. People seriously interested in kermit can read the info-kermit digest on mod.protocols.kermit. Info-kermit-request@cu20b.columbia.edu can be contacted if you need an arpanet/bitnet subscription. There is also a book on kermit by Frank Da Cruz, I have not yet read it. Kermit is available via arpanet ftp, bitnet, uucp from okstate, and on tapes. The request address above should be willing to send the details if needed. -- Bob Larson Arpa: Blarson@Usc-Eclb.Arpa Uucp: (several backbone sites)!sdcrdcf!usc-oberon!castor.usc.edu!blarson seismo!cit-vax!usc-oberon!castor.usc.edu!blarson