Path: utzoo!utgpu!watserv1!maytag!xenitec!zswamp!root From: root@zswamp.fidonet.org (Geoffrey Welsh) Newsgroups: comp.dcom.modems Subject: What should a new UUCP protocol do? Message-ID: <3778.273A4634@zswamp.fidonet.org> Date: Thu, 08 Nov 90 14:09:30 EDT Organization: Izot's Swamp BBS - Kitchener, Ontario John Antypas (johnan@ism.isc.com ) wrote: >Interactive Systems is now the fortunate owner of many >different modems. >Some are Telebits, some are V.32, some are 2400 baud >no-namers, etc. >Unfortunately, we do UUCP with all of them. You are just the sort of person I (and, I am sure, many others) need to chat with! (I sense you running away already.) Could you list the modems you use and your impressions of them? Any glaring problems? Perhaps you'd categorize them as 'perfect' , 'good', 'workable' and 'NFG'? The modem market is so confusing today. Many people come to me asking for recommendations... at 9600 bps, the answer was usually easy, dictated by the application: UUCP implied Telebit, BBSing implied USRobotics. At 2400, I always named Hayes because I can be sure that the product is good and the service excellent. However, most 2400 bps buyers turn away when they hear that. They don't want to pay Hayes prices, and I'm at a loss to suggest reliable, let alone comparable, 2400 bps modems that are not as expensive as Hayes'. V.32 opens a whole new can of worms. I am about to embark on a V.32 modem evaluation spree which may include GVC, USRobotics, Practical Peripherals, ATI, and Lord knows who else. >We are looking into placing a new protocol into UUCP which >copes with >the higher-speed modems, but doesn't require protocol >spoofing, nor >does it assume your running X.25 (no f protocol). What >characteristics >should we shoot for when dealing with what we call, the new >low-end >high speed modem. Basically, this 'problem' has already been solved outside of the UUCP world, and the answer looks a lot like Omen Technologies' ZMODEM. FidoNet, which deals with the lack of Usenet's financial resources by squeezing every bit of efficiency it can, uses a protocol called ZedZap (among others), a ZMODEM type protocol whioch allows for much larger block sizes than the original ZMODEM spec (8K at 9600 bps). ZMODEM provides much larger data blocks than UUCP-g, meaning lower overhead. It doesn't require ACKs during an error-free transfer, meaning that it will work well with PEP, V.29, and other unidirectional carriers. It does correct errors when necessary, so a guaranteed error-free link isn't necessary (unlike UUCP-e), but having one does help throughput. The downside is that streaming protocols like ZMODEM require perfect co-ordination of handshaking between the modems and their hosts. UUCP-g doesn't, if you assume (or provide) a buffer at every point that exceeds the maximum window size. >Can do 9600 baud without compression, but with compression >can do 38.4K Leave that up to hardware compression on the modems (PEP2, MNP5, V.42bis) or precompress the data (like compressed batched news). >Either does not have a back channel, or must "turn the >channel around" and can take a second or so to do it. The only solution to this is a streaming protocol. >I've been looking at a modified 'g' protocol using 2K blocks >window size 7. This would still require an ACK (implying a carrier reversal) every block (2K at PEP speeds is 1.5 - 2 seconds; do you want to induce up to 30 pairs of carrier reversals every minute? >Tell us what you want, maybe we can put it in. I think that a ZMODEM-based UUCP protocol is long overdue. No protocol is perfect under all circumstances, but ZMODEM is a fairly versatile protocol with relatively high efficiency (especially compared to other 'universal' protocols like Kermit!) Disclaimer: I don't own or operate an Interactive Systems OS. I can't recall ever *seeing* one. My suggestion is made in good faith as my worthy deed of the day. You're not going to increase your revenue from me by taking up the idea, nor do I proimise to abandon all my worldly posessions and sell ISC products. -- UUCP: watmath!xenitec!zswamp!root | 602-66 Mooregate Crescent Internet: root@zswamp.fidonet.org | Kitchener, Ontario FidoNet: SYSOP, 1:221/171 | N2M 5E6 CANADA Data: (519) 742-8939 | (519) 741-9553 MC Hammer, n. Device used to ensure firm seating of MicroChannel boards Try our new Bud 'C' compiler... it specializes in 'case' statements!