Path: utzoo!mnetor!uunet!van-bc!sl From: sl@van-bc.UUCP (pri=-10 Stuart Lynne) Newsgroups: comp.dcom.modems Subject: Re: What the world needs is a protocol for high-speed, error free modems Message-ID: <1731@van-bc.UUCP> Date: 26 Apr 88 19:19:42 GMT References: <1576@looking.UUCP> Reply-To: sl@van-bc.UUCP (Stuart Lynne) Organization: Public Access Network, Vancouver, BC. Lines: 46 In article <1576@looking.UUCP> brad@looking.UUCP (Brad Templeton) writes: >Now that I've got a telebit, I'm actually noticing more waste in my >With the speed and error correcting nature of these and other modems, such >as 9600 baud MNP modems, using the various protocols we've got with short >packets and lots of backtalk, along with slow handshaking. >What we need is a protocol that: > a) Bunches up all the files before initiating the call, so it's > just a constant data stream > b) Uses big fat packets, 10K or 20K in size. > (or uses a packet time in seconds rather than bytes, ie > "5 seconds" means 150 bytes at 300 baud and ~5K at 9600 baud.) > c) Does minimal error checking, ie. one CRC per 10K packet. > d) Can use a restricted character set so that more efficient > 'line at a time' tty driver modes can be used, and also so > that LANS and packet switch nets don't interfere. > e) Possibly uses shorter packets but doesn't actually wait for the > ACK before sending the next packet, but rather sits and examines > any NAKs that come or ACKS that don't, and resends those packets. You are confusing two issues here. We need two protocols. A file transfer protocol which can "batch" small things together for transfer, and a more effective transport protocol which can be more efficently implemented on micros and mini's. In the first instance, there has been some discussion about using BSMTP to allow multiple mail messages to be transferred in one file. For the second problem what you described sounds a lot like ZMODEM. It was designed with a lot of these issue's in mind and attempts to be efficent both from the use of the available bandwidth and CPU cycles for implementing. -- {ihnp4!alberta!ubc-vision,uunet}!van-bc!Stuart.Lynne Vancouver,BC,604-937-7532