caf@omen.UUCP (Chuck Forsberg WA7KGX) (05/20/89)
In article <25165@coherent.com> dplatt@coherent.com (Dave Platt) writes:
...
:ZMODEM can, at least, deal with situations in which the reverse path
:(receiver-to-transmitter) is not 8-bit-transparent... this covers a
:large percentage of the download-lots-of-data-over-a-network situations.
:This was the purpose for which it was engineered... it was designed to
:permit people to download data, rapidly and effectively, over the sorts
:of packet-switching nets that the people-who-paid-for-its-design were
:running. My impression is that there was less emphasis laid on its
:ability to permit _uploading_ of data over these same networks; I could
:very well be wrong. [Chuck... care to comment, if you're following this
:thread?]
ZMODEM's hex packets are there to allow downloading from timesharing
systems where it is inconvenient or impossible to put the "keyboard"
into a pure 8 bit binary totally transparent mode. ZMODEM's support
for an extensible number of packet formats independent of the higher
level logic of the protocol, and its ability to use whichever of these
types is suited to the situation is unique among the popular protocols.
From its inception ZMODEM was designed with the hooks to allow for
operation over 7 bit networks by adding new packet/frame types.
Wishing to avoid Kermits 7/8 bit handshake problems and Kermit's
slow speed, I have not rushed ahead into territory where I am not
familiar with the types of data files that are most popular.
My current thinking for 7 bit paths is to add two new frame types.
The first would use RLE compression and 8th bit escaping, not
too much different from Kermit except that Kermit escapes ALL
control characters, while this is an option with ZMODEM. This
would be useful for test files that don't have too many
characters >127.
The second would pack N 8 bit characters into N+M bytes either
by shifting of bits or DEC RADIX50 style packing. There are
many tradeoffs between packing efficiency, output character
set, computational intensity, and code portability here, and
suggestions are welcome.
Some grant money to support these developments would also
come in handy.
Chuck Forsberg WA7KGX ...!tektronix!reed!omen!caf
Author of YMODEM, ZMODEM, Professional-YAM, ZCOMM, and DSZ
Omen Technology Inc "The High Reliability Software"
17505-V NW Sauvie IS RD Portland OR 97231 503-621-3406
TeleGodzilla:621-3746 FAX:621-3735 CIS:70007,2304 Genie:CAFles@chinet.chi.il.us (Leslie Mikesell) (05/25/89)
In article <769@omen.UUCP> caf@omen.UUCP (Chuck Forsberg WA7KGX) writes: >My current thinking for 7 bit paths is to add two new frame types. >The first would use RLE compression and 8th bit escaping, not >too much different from Kermit except that Kermit escapes ALL >control characters, while this is an option with ZMODEM. This >would be useful for test files that don't have too many >characters >127. > >The second would pack N 8 bit characters into N+M bytes either >by shifting of bits or DEC RADIX50 style packing. There are >many tradeoffs between packing efficiency, output character >set, computational intensity, and code portability here, and >suggestions are welcome. How about sending one packet each direction of the known characters that must be escaped kermit-style (escaped, of course). Some shorthand notation for "all control characters" and "all characters >127" could be used here. Then for compression, how about building packets at least 1K in size and not necessarily alligned with the transmission packets that would have [START-CODE][RLE-PREFIX][ENCODING-METHOD][LENGTH][data....] where RLE-PREFIX would be chosen as the least frequent character in the packet, and the ENCODING-METHOD of choice would use a non-adaptive huffman or LZW compression with the tree built into both ends. If applying this compression does not reduce the size, then ENCODING-METHOD would be set to NONE and sent uncompressed. (Thus you don't have to send the tree, you can recover an interrupted stream, and you never grow more than the packet header when compression doesn't work). This stream would then go into the normal ZMODEM packets. Alternate encoding-methods could be used, perhaps to optimize the output character set to the known restrictions of the link. Les Mikesell