From: dwh@vaxeline.ftp.com (David W. Hamaker)
Newsgroups: comp.sys.amiga.datacomm,comp.dcom.modems,comp.protocols.misc
Subject: Re: New modem transfer protocol
Keywords: TransQ Tmodem protocol modem XPR transfer
Date: 9 Apr 92 23:27:36 GMT
Article-I.D.: vaxeline.1992Apr9.232736.19100
Organization: FTP Software, Inc., Wakefield, MA

(This is a reposting of article <1992Mar25.010455.11716@vaxeline.ftp.com>
originally posted Mar 25; there were posting problems here.)

In article <1992Mar24.100148.21762@leland.Stanford.EDU> kocherp@leland.Stanford.EDU (Paul Carl Kocher) writes:
>In article <l9ktxg=@rpi.edu> husaim@aix.rpi.edu (Mohammad Mughees Husain) writes:
>> [...]   With this protocol one WILL be able to transfer at
>>100% of their modem speed and STILL have error correction!!!
>>[...]  The CRC is created at the receiving end 
>>and sent back to the transmitter.
>>[...]  If the CRC is wrong, the block is re-sent.
>
>While you can certainly get slight speed increases over existing
>protocols, you can't ever hit 100% performance.  Here, for example,
>you waste *some* time when the transmitter tells the reciever whether
>each block is a repeat of a defective one or a brand new one.  Only
>on error-free links is 100% speed even a possibility.

You can _imply_ each "block" is a new one and incur the overhead only
when signaling error retransmission, for all practical purposes.  Thus,
except for nits, you _can_ hit 100% when the transmission is clean, which
is the main issue here.

>This protocol doesn't sound robust enough to deal with common line 
>noise.  Without sacrificing more speed, it's going to be very
>difficult to survive line errors like missing characters.  You
>have to assign codes that indicate beginning/end of packets,
>errors, etc.  For example, my modem loses all incoming characters
>for about 1 second when the 'fridge turns on :-).  A good protocol
>has to be able to survive this kind of thing.  Here, since no
>characters have been reserved for special commands, the transmitter
>has no way to tell the reciever if something goes wrong.  Unfortunately
>faults over the phone line are often far more complex than simple
>character substitution, and it will be no small challenge to make
>this new protocol "more fault tolerant than zmodem and the like."
>Few users to need raw speed are using full-duplex non-error-correcting
>modems anyway.

I don't think he said enough about this aspect for you to conclude this.
He probably is going to need to reserve something for "special commands"
but this does not mean he needs explicit packet framing to succeed.  In
my own work in this area I felt giving one character code special meaning,
providing a way to remap this character in the data to a little-used one,
and using two characters to represent the special code, was "good enough."
This also impacted my choice of "go back n" recovery, but I would have
done so anyway because "go back n" is simpler than selective retransmision.

>If you decide that speed is everything, you can always try using the
>parity bit for data. This would increase your throughput from
>80% (8 data, 1 start, 1 stop bits) to 81.8% (8 data, 1 parity
>that carries data, 1 start, 1 stop).  Doing this would require some
>tricky use of the parity errors & rapid setting of even/odd parity,
>and probably wouldn't work with high-speed modems, however...

Or build in a good data compression algorithm.

>Encourage your friend to work on a protocol -- existing ones certainly
>leave room for improvement.  Designing a good, robust one is a very
>challenging task.  For example, one project that I nearly finished
>before classes started last fall was to develop a "transparent"
>fast (115Kbps) bidirectional TSR file transfer system for the PC.
>I got the code working fine over a null-modem and have acceptable
>error-correction, but don't have the time to finish the job properly
>and to port it to C (in 80x86 assembly now).  It doesn't look like
>I'll have time to write the special comm program & fossil driver
>that such a system would require.  If anyone is interested in this
>approach, send me e-mail as I doubt this kind of this is of very
>general interest...
>
>How about devoloping a protocol for connections that cannot tolerate
>particular escape characters (e.g. ^^ or ^] or ^\ for some Unix
>machines -- make it configurable) and that can handle other typical
>Unix problems.  (I have never found an efficient protocol for
>uploading to Unix machines...)

Yes, transparency issues are important.  I've never tried it, but I see
no reason why Zmodem would not be "efficient" for uploading to Unix.

>Good luck!
>-- Paul Kocher
>
>________kocherp@leland.stanford.edu_________kocherp@jacobs.cs.orst.edu________
>I am an undergrad at Stanford seeking summer work or contract jobs programming
>(IBM PC), doing technical writing, or assisting with research. Send e-mail for
>resume if interested!  - Paul Kocher/Box 13554/Stanford CA 94309, 415/497-6438

-Dave Hamaker
 cfcl!dwh@apple.com
 dwh@ftp.com