koreth@ssyx.ucsc.edu (Steven Grimm) (05/30/88)
Submitted-by: bammi@mandrill.ces.cwru.edu (Jwahar R. Bammi)
Posting-number: Volume 1, Issue 46
Archive-name: zmdm/part06
#!/bin/sh
# this is part 6 of a multipart archive
# do not concatenate these parts, unpack them in order with /bin/sh
# file UTIL.C continued
#
CurArch=6
if test ! -r s2_seq_.tmp
then echo "Please unpack part 1 first!"
exit 1; fi
( read Scheck
if test "$Scheck" != $CurArch
then echo "Please unpack part $Scheck next!"
exit 1;
else exit 0; fi
) < s2_seq_.tmp || exit 1
echo "x - Continuing file UTIL.C"
sed 's/^X//' << 'SHAR_EOF' >> UTIL.C
X#endif /* REMOTE */
X#endif /* STANDALONE */
X
X/* -eof- */
SHAR_EOF
echo "File UTIL.C is complete"
chmod 0600 UTIL.C || echo "restore of UTIL.C fails"
echo "x - extracting YMODEM.DOC (Text)"
sed 's/^X//' << 'SHAR_EOF' > YMODEM.DOC &&
X
X
X
X - 1 -
X
X
X
X XMODEM/YMODEM PROTOCOL REFERENCE
X A compendium of documents describing the
X
X XMODEM and YMODEM
X
X File Transfer Protocols
X
X
X
X
X This document was formatted 9-11-86.
X
X
X
X
X
X
X
X Edited by Chuck Forsberg
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X Please distribute as widely as possible.
X
X Questions to Chuck Forsberg
X
X
X
X
X
X Omen Technology Inc
X 17505-V Sauvie Island Road
X Portland Oregon 97231
X Voice: 503-621-3406
X Modem (Telegodzilla): 503-621-3746 Speed 1200,300
X Compuserve: 70007,2304
X UUCP: ...!tektronix!reed!omen!caf
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X - 2 -
X
X
X
X 1. ROSETTA STONE
X
X Here are some definitions which reflect the current vernacular
X in the computer media. The attempt here is identify the file
X transfer protocol rather than specific programs.
X
X XMODEM refers to the original 1979 file transfer etiquette
X introduced by Ward Christensen's 1979 MODEM2 program. It's also
X called the MODEM or MODEM2 protocol. Some who are unaware of MODEM7's
X unusual batch file mode call it MODEM7. Other aliases include "CP/M
X Users's Group" and "TERM II FTP 3". This protocol is supported by
X every serious communications program because of its universality,
X simplicity, and reasonable performance.
X
X XMODEM/CRC replaces XMODEM's 1 byte checksum with a two byte Cyclical
X Redundancy Check (CRC-16), giving modern error detection
X protection.
X
X XMODEM-1k Refers to the XMODEM/CRC protocol with 1024 byte data blocks.
X
X YMODEM refers to the XMODEM/CRC (optional 1k blocks) protocol with the
X batch transmission described below.
X
X ZMODEM uses familiar XMODEM/CRC and YMODEM technology in a
X new protocol that provides reliability, throughput, file
X management, and user amenities appropriate to contemporary
X data communications.
X
X
X 2. YET ANOTHER PROTOCOL?
X
X Since its development half a decade ago, the Ward Christensen modem
X protocol has enabled a wide variety of computer systems to interchange
X data. There is hardly a communications program that doesn't at least
X claim to support this protocol.
X
X Recent advances in computing, modems and networking have
X revealed a number of weaknesses in the original protocol:
X
X + The short block length caused throughput to suffer when used with
X timesharing systems, packet switched networks, satellite circuits,
X and buffered (error correcting) modems.
X
X + The 8 bit arithmetic checksum and other aspects allowed line
X impairments to interfere with dependable, accurate transfers.
X
X + Only one file could be sent per command. The file name had to be
X given twice, first to the sending program and then again to the
X receiving program.
X
X + The transmitted file could accumulate as many as 127 extraneous
X bytes.
X
X
X
X Chapter 2
X
X
X
X
X
X
X X/YMODEM Protocol Reference 09-11-86 3
X
X
X
X + The modification date of the file was lost.
X
X A number of other protocols have been developed over the
X years, but none have displaced XMODEM to date:
X
X + Lack of public domain documentation and example programs have kept
X proprietary protocols such as MNP, Blast, and others
X tightly bound to the fortunes of their suppliers.
X
X + Complexity discourages the widespread application of BISYNC, SDLC,
X HDLC, X.25, and X.PC protocols.
X
X + Performance compromises and moderate complexity have limited the
X popularity of the Kermit protocol, which was developed to allow file
X transfers in environments hostile to XMODEM.
X
X The XMODEM protocol extensions and YMODEM Batch address these
X weaknesses while maintaining XMODEM's simplicity.
X
X YMODEM is supported by the public domain programs YAM (CP/M),
X YAM(CP/M-86), YAM(CCPM-86), IMP (CP/M), KMD (CP/M), rz/sz (Unix, Xenix,
X VMS, Berkeley Unix, Venix, Xenix, Coherent, IDRIS, Regulus). Commerical
X implementations include MIRROR, and Professional-YAM.[1] Communications
X programs supporting these extensions have been in use since 1981.
X
X The 1k packet length (XMODEM-1k) described below may be used in
X conjunction with YMODEM Batch Protocol, or with single file transfers
X identical to the XMODEM/CRC protocol except for minimal
X changes to support 1k packets.
X
X Another extension is simply called the g option. It provides maximum
X throughput when used with end to end error correcting media,
X such as X.PC and error correcting modems, including the emerging
X 9600 bps units by Electronic Vaults and others.
X
X To complete this tome, Ward Christensen's original protocol document and
X John Byrns's CRC-16 document are included for reference.
X
X References to the MODEM or MODEM7 protocol have been changed
X to XMODEM to accommodate the vernacular. In Australia, it is
X properly called the Christensen Protocol.
X
X
X
X
X
X
X __________
X
X 1. Available for IBM PC,XT,AT, Unix and Xenix
X
X
X
X
X Chapter 2
X
X
X
X
X
X
X
X X/YMODEM Protocol Reference 09-11-86 4
X
X
X
X 2.1 Some Messages from the Pioneer
X
X #: 130940 S0/Communications 25-Apr-85 18:38:47
X Sb: my protocol
X Fm: Ward Christensen 76703,302 (EDITED)
X To: all
X
X Be aware the article[2] DID quote me correctly in terms of the
X phrases like "not robust", etc.
X
X It was a quick hack I threw together, very unplanned (like
X everything I do), to satisfy a personal need to communicate with
X "some other" people.
X
X ONLY the fact that it was done in 8/77, and that I put it in the public
X domain immediately, made it become the standard that it is.
X
X I think its time for me to
X
X (1) document it; (people call me and say "my product is going
X to include it - what can I 'reference'", or "I'm writing a
X paper on it, what do I put in the bibliography") and
X
X (2) propose an "incremental extension" to it, which might take
X "exactly" the form of Chuck Forsberg's YAM protocol. He
X wrote YAM in C for CP/M and put it in the public domain,
X and wrote a batch protocol for Unix[3] called rb and sb
X (receive batch, send batch), which was basically XMODEM with
X (a) a record 0 containing filename date time and size
X (b) a 1K block size option
X (c) CRC-16.
X
X He did some clever programming to detect false ACK or EOT, but basically
X left them the same.
X
X People who suggest I make SIGNIFICANT changes to the protocol,
X such as "full duplex", "multiple outstanding blocks", "multiple
X destinations", etc etc don't understand that the incredible
X simplicity of the protocol is one of the reasons it survived to
X this day in as many machines and programs as it may be found in!
X
X Consider the PC-NET group back in '77 or so - documenting to
X beat the band
X - THEY had a protocol, but it was "extremely complex", because
X it tried to be "all things to all people" - i.e. send binary
X files on a 7-bit system, etc. I was not that "benevolent". I
X (emphasize > I < ) had an 8-bit UART,
X
X
X __________
X
X 2. Infoworld April 29 p. 16
X
X 3. VAX/VMS versions of these programs are also available.
X
X
X
X
X Chapter 2
X
X
X
X
X
X
X
X X/YMODEM Protocol Reference 09-11-86 5
X
X
X
X so "my protocol was an 8-bit protocol", and I would just say "sorry" to
X people who were held back by 7-bit limitations. ...
X
X Block size: Chuck Forsberg created an extension of my protocol,
X called YAM, which is also supported via his public domain
X programs for UNIX called rb and sb - receive batch and send
X batch. They cleverly send a "block 0" which contains the
X filename, date, time, and size. Unfortunately, its UNIX style,
X and is abit weird[4] - octal numbers, etc. BUT, it is a nice way
X to overcome the kludgy "echo the chars of the name" introduced
X with MODEM7. Further, chuck uses CRC-16 and optional 1K blocks.
X Thus the record 0, 1K, and CRC, make it a "pretty slick new
X protocol" which is not significantly different from my own.
X
X Also, there is a catchy name - YMODEM. That means to some
X that it is the "next thing after XMODEM", and to others that it
X is the Y(am)MODEM protocol. I don't want to emphasize that too
X much - out of fear that other mfgrs might think it is a
X "competitive" protocol, rather than an "unaffiliated" protocol.
X Chuck is currently selling a much-enhanced version of his
X CP/M-80 C program YAM, calling it Professional Yam, and its
X for the PC - I'm using it right now. VERY slick! 32K capture buffer,
X script, scrolling, previously captured text search, plus
X built-in commands for just about everything - directory (sorted
X every which way), XMODEM, YMODEM, KERMIT, and ASCII file
X upload/download, etc. You can program it to "behave" with most
X any system - for example when trying a number for CIS it detects
X the "busy" string back from the modem and substitutes a diff
X phone # into the dialing string and branches back to try it.
X
X
X
X 3. XMODEM PROTOCOL ENHANCEMENTS
X
X This chapter discusses the protocol extensions to Ward Christensen's
X 1982 XMODEM protocol description document.
X
X The original document recommends the user be asked whether to continue
X trying or abort after 10 retries. Most programs no longer ask the
X operator whether he wishes to keep retrying. Virtually all correctable
X errors are corrected within the first few retransmissions. If
X the line is so bad that ten attempts are insufficient, there is
X a significant danger of undetected errors. If the connection is
X that bad, it's better to redial for a better connection, or
X mail a floppy disk.
X
X
X
X
X
X __________
X
X 4. The file length, time, and file mode are optional.The pathname and
X file length may be sent alone if desired.
X
X
X
X
X Chapter 3 XMODEM Protocol Enhancements
X
X
X
X
X
X
X
X X/YMODEM Protocol Reference 09-11-86 6
X
X
X
X 3.1 Graceful Abort
X
X The YAM and Professional-YAM X/YMODEM routines recognize a
X sequence of two consecutive CAN (Hex 18) characters without modem
X errors (overrun, framing, etc.) as a transfer abort command. This
X sequence is recognized when YAM is waiting for the beginning of a
X packet or for an acknowledge to one that has been sent. The
X check for two consecutive CAN characters virtually eliminates the
X possibility of a line hit aborting the transfer. YAM sends
X eight CAN characters when it aborts an XMODEM, YMODEM, or ZMODEM
X protocol file transfer. Pro-YAM then sends eight backspaces to delete
X the CAN characters from the remote's keyboard input buffer, in
X case the remote had already aborted the transfer and was
X awaiting a keyboarded command.
X
X
X 3.2 CRC-16 Option
X
X The XMODEM protocol uses an optional two character CRC-16
X instead of the one character arithmetic checksum used by the original
X protocol and by most commercial implementations. CRC-16
X guarantees detection of all single and double bit errors, all errors
X with an odd number of error bits, all burst errors of length 16 or
X less, 99.9969% of all 17-bit error bursts, and 99.9984 per cent
X of all possible longer error bursts. By contrast, a double bit
X error, or a burst error of 9 bits or more can sneak past the
X XMODEM protocol arithmetic checksum.
X
X The XMODEM/CRC protocol is similar to the XMODEM protocol,
X except that the receiver specifies CRC-16 by sending C (Hex
X 43) instead of NAK when requesting the FIRST packet. A two
X byte CRC is sent in place of the one byte arithmetic checksum.
X
X YAM's c option to the r command enables CRC-16 in single file
X reception, corresponding to the original implementation in the
X MODEM7 series programs. This remains the default because many
X commercial communications programs and bulletin board systems still do
X not support CRC-16, especially those written in Basic or Pascal.
X
X XMODEM protocol with CRC is accurate provided both sender and
X receiver both report a successful transmission. The protocol is robust
X in the presence of characters lost by buffer overloading on
X timesharing systems.
X
X The single character ACK/NAK responses generated by the
X receiving program adapt well to split speed modems, where the reverse
X channel is limited to ten per cent or less of he main channel's speed.
X
X XMODEM and YMODEM are half duplex protocols which do not attempt to
X transmit information and control signals in both directions at the same
X time. This avoids buffer overrun problems that have been reported by
X users attempting to exploit full duplex asynchronous file transfer
X protocols such as Blast.
X
X Professional-YAM adds several proprietary logic enhancements to XMODEM's
X
X
X
X Chapter 3 XMODEM Protocol Enhancements
X
X
X
X
X
X
X
X X/YMODEM Protocol Reference 09-11-86 7
X
X
X
X error detection and recovery. These compatible enhancements eliminate
X most of the bad file transfers other programs make when using
X the XMODEM protocol under less than ideal conditions.
X
X
X 3.3 XMODEM-1k 1024 Byte Packet
X
X The choice to use 1024 byte packets is expressed to the sending
X program on its command line or selection menu.[1] 1024 byte packets
X improve throughput in many applications, but some environments cannot
X accept 1024 byte bursts, especially minicomuters running 19.2kb
X ports.
X
X An STX (02) replaces the SOH (01) at the beginning of the transmitted
X block to notify the receiver of the longer packet length. The
X transmitted packet contains 1024 bytes of data. The receiver
X should be able to accept any mixture of 128 and 1024 byte
X packets. The packet number is incremented by one for each
X packet regardless of the packet length.
X
X The sender must not change between 128 and 1024 byte packet lengths if it
X has not received a valid ACK for the current packet. Failure to observe
X this restriction allows certain transmission errors to pass undetected.
X
X If 1024 byte packets are being used, it is possible for a file to "grow"
X up to the next multiple of 1024 bytes. This does not waste disk space if
X the allocation granularity is 1k or greater. With YMODEM batch
X transmission, the optional file length transmitted in the file
X name packet allows the receiver to discard the padding,
X preserving the exact file length and contents.
X
X 1024 byte packets may be used with batch file transmission or with single
X file transmission. CRC-16 should be used with the k option to preserve
X data integrity over phone lines. If a program wishes to enforce this
X recommendation, it should cancel the transfer, then issue an informative
X diagnostic message if the receiver requests checksum instead of CRC-16.
X Under no circumstances may a sending program use CRC-16 unless the
X receiver commands CRC-16.
X
X
X 4. YMODEM Batch File Transmission
X
X The YMODEM Batch protocol is an extension to the XMODEM/CRC protocol that
X allows 0 or more files to be transmitted with a single command. (Zero
X files may be sent if none of the requested files is accessible.) The
X design approach of the YMODEM Batch protocol is to use the
X normal routines for sending and receiving XMODEM packets in a
X layered fashion similar to
X
X
X __________
X
X 1. See "KMD/IMP Exceptions to YMODEM" below.
X
X
X
X
X Chapter 4 XMODEM Protocol Enhancements
X
X
X
X
X
X
X
X X/YMODEM Protocol Reference 09-11-86 8
X
X
X
X Figure 1. 1024 byte Packets
X
X SENDER RECEIVER
X "s -k foo.bar"
X "foo.bar open x.x minutes"
X C
X STX 01 FE Data[1024] CRC CRC
X ACK
X STX 02 FD Data[1024] CRC CRC
X ACK
X STX 03 FC Data[1000] CPMEOF[24] CRC CRC
X ACK
X EOT
X ACK
X
X Figure 2. Mixed 1024 and 128 byte Packets
X
X SENDER RECEIVER
X "s -k foo.bar"
X "foo.bar open x.x minutes"
X C
X STX 01 FE Data[1024] CRC CRC
X ACK
X STX 02 FD Data[1024] CRC CRC
X ACK
X SOH 03 FC Data[128] CRC CRC
X ACK
X SOH 04 FB Data[100] CPMEOF[28] CRC CRC
X ACK
X EOT
X ACK
X
X packet switching methods.
X
X Why was it necessary to design a new batch protocol when one already
X existed in MODEM7?[1] The batch file mode used by MODEM7 is unsuitable
X because it does not permit full pathnames, file length, file date, or
X other attribute information to be transmitted. Such a restrictive design,
X hastily implemented with only CP/M in mind, would not have permitted
X extensions to current areas of personal computing such as Unix, DOS, and
X object oriented systems. In addition, the MODEM7 batch file mode is
X somewhat susceptible to transmission impairments.
X
X
X
X __________
X
X 1. The MODEM7 batch protocol transmitted CP/M FCB bytes f1...f8 and
X t1...t3 one character at a time. The receiver echoed these bytes as
X received, one at a time.
X
X
X
X
X Chapter 4 XMODEM Protocol Enhancements
X
X
X
X
X
X
X
X X/YMODEM Protocol Reference 09-11-86 9
X
X
X
X As in the case of single a file transfer, the receiver initiates batch
X file transmission by sending a "C" character (for CRC-16).
X
X The sender opens the first file and sends packet number 0 with the
X following information.[2]
X
X Only the pathname (file name) part is required for batch transfers.
X
X To maintain upwards compatibility, all unused bytes in packet 0 must be
X set to null.
X
X Pathname The pathname (conventionally, the file name) is sent as a null
X terminated ASCII string. This is the filename format used by the
X handle oriented MSDOS(TM) functions and C library fopen functions.
X An assembly language example follows:
X DB 'foo.bar',0
X No spaces are included in the pathname. Normally only the file name
X stem (no directory prefix) is transmitted unless the sender has
X selected YAM's f option to send the full pathname. The source drive
X (A:, B:, etc.) is never sent.
X
X Filename Considerations:
X
X + File names should be translated to lower case unless the sending
X system supports upper/lower case file names. This is a
X convenience for users of systems (such as Unix) which store
X filenames in upper and lower case.
X
X + The receiver should accommodate file names in lower and upper
X case.
X
X + When transmitting files between different operating systems,
X file names must be acceptable to both the sender and receiving
X operating systems.
X
X If directories are included, they are delimited by /; i.e.,
X "subdir/foo" is acceptable, "subdir\foo" is not.
X
X Length The file length and each of the succeeding fields are optional.[3]
X The length field is stored in the packet as a decimal
X string counting the number of data bytes in the file. The
X file length does not include any CPMEOF (^Z) or other
X garbage characters used to pad the last packet.
X
X
X __________
X
X 2. Only the data part of the packet is described here.
X
X 3. Fields may not be skipped.
X
X
X
X
X Chapter 4 XMODEM Protocol Enhancements
X
X
X
X
X
X
X
X X/YMODEM Protocol Reference 09-11-86 10
X
X
X
X If the file being transmitted is growing during transmission, the
X length field should be set to at least the final expected file
X length, or not sent.
X
X The receiver stores the specified number of characters, discarding
X any padding added by the sender to fill up the last packet.
X
X Modification Date The mod date is optional, and the filename and length
X may be sent without requiring the mod date to be sent.
X
X Iff the modification date is sent, a single space separates the
X modification date from the file length.
X
X The mod date is sent as an octal number giving the time the contents
X of the file were last changed, measured in seconds from Jan 1 1970
X Universal Coordinated Time (GMT). A date of 0 implies the
X modification date is unknown and should be left as the date the file
X is received.
X
X This standard format was chosen to eliminate ambiguities
X arising from transfers between different time zones.
X
X Two Microsoft blunders complicate the use of modification dates in
X file transfers with MSDOS(TM) systems. The first is the lack of
X timezone standardization in MS-DOS. A file's creation time can not
X be known unless the timezone of the system that wrote the file[4] is
X known. Unix solved this problem (for planet Earth, anyway) by
X stamping files with Universal Time (GMT). Microsoft would have to
X include the timezone of origin in the directory entries, but does
X not. Professional-YAM gets around this problem by using the z
X parameter which is set to the number of minutes local time lags GMT.
X For files known to originate from a different timezone, the -zT
X option may be used to specify T as the timezone for an individual
X file transfer.
X
X The second problem is the lack of a separate file creation date in
X DOS. Since some backup schemes used with DOS rely on the file
X creation date to select files to be copied to the archive, back-
X dating the file modification date could interfere with the safety of
X the transferred files. For this reason, Pro-YAM does not modify the
X date of received files with the header information unless the d
X numeric parameter is non zero.
X
X
X
X
X
X __________
X
X 4. Not necessarily that of the transmitting system!
X
X
X
X
X Chapter 4 XMODEM Protocol Enhancements
X
X
X
X
X
X
X
X X/YMODEM Protocol Reference 09-11-86 11
X
X
X
X Mode Iff the file mode is sent, a single space separates the file mode
X from the modification date. The file mode is stored as an octal
X string. Unless the file originated from a Unix system, the
X file mode is set to 0. rb(1) checks the file mode for the
X 0x8000 bit which indicates a Unix type regular file. Files
X with the 0x8000 bit set are assumed to have been sent from
X another Unix (or similar) system which uses the same file
X conventions. Such files are not translated in any way.
X
X
X Serial Number Iff the serial number is sent, a single space separates the
X serial number from the file mode. The serial number of the
X transmitting program is stored as an octal string.
X Programs which do not have a serial number should omit this
X field, or set it to 0. The receiver's use of this field is
X optional.
X
X
X Other Fields YMODEM was designed to allow additional header fields to be
X added as above without creating compatibility problems with older
X YMODEM programs. Please contact Omen Technology if other fields are
X needed for special application requirements.
X
X The rest of the packet is set to nulls. This is essential to preserve
X upward compatibility.[5]
X
X If the filename packet is received with a CRC or other error, a
X restrnsmission is requested. After the filename packet has been
X received, it is ACK'ed if the write open is successful. If the
X file cannot be opened for writing, the receiver cancels the
X transfer with CAN characters as described above.
X
X The receiver then initiates transfer of the file contents
X according to the standard XMODEM/CRC protocol.
X
X After the file contents have been transmitted, the receiver
X again asks for the next pathname. Transmission of a null
X pathname terminates batch file transmission. Note that
X transmission of no files is not necessarily an error. This is
X possible if none of the files requested of the sender could be
X opened for reading.
X
X In batch transmission, the receiver automatically requests CRC-16.
X
X The Unix programs sz(1) and rz(1) included in the source code file
X
X
X __________
X
X 5. If, perchance, this information extends beyond 128 bytes (possible
X with Unix 4.2 BSD extended file names), the packet should be
X sent as a 1k packet as described above.
X
X
X
X
X Chapter 4 XMODEM Protocol Enhancements
X
X
X
X
X
X
X
X X/YMODEM Protocol Reference 09-11-86 12
X
X
X
X RZSZ[12].SHQ (rzsz1.sh, rzsz2.sh) should answer other questions about
X YMODEM batch protocol.
X
X Figure 3. YMODEM Batch Transmission Session
X
X SENDER RECEIVER
X "sb foo.*<CR>"
X "sending in batch mode etc."
X C (command:rb)
X SOH 00 FF foo.c NUL[123] CRC CRC
X ACK
X C
X SOH 01 FE Data[128] CRC CRC
X ACK
X STX 02 FD Data[1024] CRC CRC
X ACK
X SOH 03 FC Data[128] CRC CRC
X ACK
X SOH 04 FB Data[100] CPMEOF[28] CRC CRC
X ACK
X EOT
X NAK
X EOT
X ACK
X C
X SOH 00 FF NUL[128] CRC CRC
X ACK
X
X Figure 4. YMODEM Filename packet transmitted by sz
X
X -rw-r--r-- 6347 Jun 17 1984 20:34 bbcsched.txt
X
X 00 0100FF62 62637363 6865642E 74787400 |...bbcsched.txt.|
X 10 36333437 20333331 34373432 35313320 |6347 3314742513 |
X 20 31303036 34340000 00000000 00000000 |100644..........|
X 30 00000000 00000000 00000000 00000000
X 80 000000CA 56
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X Chapter 4 XMODEM Protocol Enhancements
X
X
X
X
X
X
X
X X/YMODEM Protocol Reference 09-11-86 13
X
X
X
X Figure 5. YMODEM Header Information used by various programs
X
X _____________________________________________________________________
X | Program | Batch | Length | Date | Mode | S/N | 1k-Blk | g-Option |
X |___________|_______|________|______|______|_____|________|__________|
X |Unix rz/sz | yes | yes | yes | yes | no | yes | sb only |
X |___________|_______|________|______|______|_____|________|__________|
X |VMS rb/sb | yes | yes | no | no | no | yes | no |
X |___________|_______|________|______|______|_____|________|__________|
X |Pro-YAM | yes | yes | yes | no | yes | yes | yes |
X |___________|_______|________|______|______|_____|________|__________|
X |CP/M YAM | yes | no | no | no | no | yes | no |
X |___________|_______|________|______|______|_____|________|__________|
X |KMD/IMP | yes | ? | no | no | no | yes | no |
X |___________|_______|________|______|______|_____|________|__________|
X
X 4.1 KMD/IMP Exceptions to YMODEM
X
X KMD and IMP character sequence emitted by the receiver (CK) to
X automatically trigger the use of 1024 byte packets as an alternative to
X specifying this option on this command line. Although this two character
X sequence works well on single process micros in direct communication,
X timesharing systems and packet switched networks can separate the
X successive characters by several seconds, rendering this method
X unreliable.
X
X Sending programs may detect the CK sequence if the operating enviornment
X does not preclude reliable implementation.
X
X Receiving programs should retain the option of sending the
X standard YMODEM C (not CK) trigger with the standard 10 second
X timeout to insure compatibility with newer forms of
X telecommunications technology.
X
X
X
X 5. YMODEM-g File Transmission
X
X Developing technology is providing phone line data transmission at ever
X higher speeds using very specialized techniques. These high
X speed modems, as well as session protocols such as X.PC, provide
X high speed, error free communications at the expense of
X considerably increased delay time.
X
X This delay time is moderate compared to human interactions, but it
X cripples the throughput of most error correcting protocols.
X
X The g option to YMODEM has proven effective under these circumstances.
X The g option is driven by the receiver, which initiates the
X batch transfer by transmitting a G instead of C. When the
X sender recognizes the G, it bypasses the usual wait for an ACK
X to each transmitted packet, sending succeeding packets at full
X speed, subject to XOFF/XON or other flow control exerted by the medium.
X
X
X
X Chapter 5 XMODEM Protocol Enhancements
X
X
X
X
X
X
X
X X/YMODEM Protocol Reference 09-11-86 14
X
X
X
X The sender expects an inital G to initiate the transmission of a
X particular file, and also expects an ACK on the EOT sent at the end of
X each file. This synchronization allows the receiver time to open and
X close files as necessary.
X
X If an error is detected in a YMODEM-g transfer, the receiver aborts the
X transfer with the multiple CAN abort sequence. The ZMODEM protocol should
X be used in applications that require both streaming throughput and error
X recovery.
X
X Figure 6. YMODEM-g Transmission Session
X
X SENDER RECEIVER
X "sb foo.*<CR>"
X "sending in batch mode etc..."
X G (command:rb -g)
X SOH 00 FF foo.c NUL[123] CRC CRC
X G
X SOH 01 FE Data[128] CRC CRC
X STX 02 FD Data[1024] CRC CRC
X SOH 03 FC Data[128] CRC CRC
X SOH 04 FB Data[100] CPMEOF[28] CRC CRC
X EOT
X ACK
X G
X SOH 00 FF NUL[128] CRC CRC
X
X
X 6. XMODEM PROTOCOL OVERVIEW
X
X 8/9/82 by Ward Christensen.
X
X I will maintain a master copy of this. Please pass on changes or
X suggestions via CBBS/Chicago at (312) 545-8086, CBBS/CPMUG (312) 849-1132
X or by voice at (312) 849-6279.
X
X 6.1 Definitions
X
X <soh> 01H
X <eot> 04H
X <ack> 06H
X <nak> 15H
X <can> 18H
X <C> 43H
X
X
X
X
X
X
X
X
X
X
X Chapter 6 Xmodem Protocol Overview
X
X
X
X
X
X
X
X X/YMODEM Protocol Reference 09-11-86 15
X
X
X
X 6.2 Transmission Medium Level Protocol
X
X Asynchronous, 8 data bits, no parity, one stop bit.
X
X The protocol imposes no restrictions on the contents of the data being
X transmitted. No control characters are looked for in the 128-byte data
X messages. Absolutely any kind of data may be sent - binary, ASCII, etc.
X The protocol has not formally been adopted to a 7-bit environment for the
X transmission of ASCII-only (or unpacked-hex) data , although it could be
X simply by having both ends agree to AND the protocol-dependent data with
X 7F hex before validating it. I specifically am referring to the
X checksum, and the block numbers and their ones- complement.
X
X Those wishing to maintain compatibility of the CP/M file structure, i.e.
X to allow modemming ASCII files to or from CP/M systems should follow this
X data format:
X
X + ASCII tabs used (09H); tabs set every 8.
X
X + Lines terminated by CR/LF (0DH 0AH)
X
X + End-of-file indicated by ^Z, 1AH. (one or more)
X
X + Data is variable length, i.e. should be considered a continuous
X stream of data bytes, broken into 128-byte chunks purely for the
X purpose of transmission.
X
X + A CP/M "peculiarity": If the data ends exactly on a 128-byte
X boundary, i.e. CR in 127, and LF in 128, a subsequent sector
X containing the ^Z EOF character(s) is optional, but is preferred.
X Some utilities or user programs still do not handle EOF without ^Zs.
SHAR_EOF
echo "End of part 6"
echo "File YMODEM.DOC is continued in part 7"
echo "7" > s2_seq_.tmp
exit 0