Synchronet v3.19b-Win32 (install) has been released (Jan-2022).

You can donate to the Synchronet project using PayPal.

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
ref:zmodem [2020/11/28 16:32] – [ZMODEM Frame] Clarify HEX frames digital manref:zmodem [2021/06/29 15:34] (current) – [ZFILE FRAME FILE INFORMATION SUBPACKET] footnote about path/file names with spaces (they are in fact supported in most ZMODEM implemenations) digital man
Line 67: Line 67:
  
 ==== ZMODEM Frame ==== ==== ZMODEM Frame ====
-There 2 classes of ZMODEM Frames: +There are 2 classes of ZMODEM Frames: 
-  * Hexadecimal (HEX) frames, contain only US-ASCII characters +  - Hexadecimal (HEX) frames, containing only US-ASCII characters 
-  * Binary (BIN16 or BIN32) frames, contain //almost// all possible 8-bit octet values+  - Binary (BIN16 or BIN32) frames, containing //almost// all possible octet values
  
 === HEX Frame === === HEX Frame ===
   <frame header> [CR] LF [XON]   <frame header> [CR] LF [XON]
  
-HEX frames are terminated with an ASCII linefeed character.+HEX frames are terminated with an ASCII linefeed character. Some ZMODEM implementations send the HEX frame terminating linefeed character with the high bit set (0x8A, that's ASCII-LF with an even-parity bit set). Also, for some HEX frame types, the frame terminator may be followed by an XON (0x11) character ("transmit on" in so-called "software flow control").
  
 === Binary Frame === === Binary Frame ===
Line 82: Line 82:
  
 ==== Frame Header ==== ==== Frame Header ====
-  <frame encoding> <frame type> <frame info> <crc>+  <frame encoding> <frame type> <frame info> <checksum>
  
-**Frame Encoding** (single byte): HEX ('''B'''), BIN16 ('''A'''), or BIN32 ('''C''').\\ +**Frame Encoding** (single byte):
-All frames sent by the "receiver" must use HEX encoding.+
  
-**Frame Type** (single byte): ZDATA, ZRPOS, ZACK, ZEOF, etc.+The //Frame Encoding// is also sometimes called the "Frame Style".
  
-**Frame Info**: Up to 15 bytes (but typically 4) of frame type-specific information. Note that later claims of //16// bytes of possible frame header data include the //Frame Type// byte.+^ Style  ^  AKA   ^ Value          ^ Frame Contents                       ^ Checksum   ^ 
 +| HEX    | ZHEX   | ASCII '''B'''  | Hexadecimal/US-ASCII characters only | 16-bit CRC | 
 +| BIN16  | ZBIN   | ASCII '''A'''  | Binary                               | 16-bit CRC | 
 +| BIN32  | ZBIN32 | ASCII '''C'''  | Binary                               | 32-bit CRC | 
 + 
 +Notes: 
 +  * All frames sent by the "receiver" must use HEX encoding.  
 + 
 +**Frame Type** (single byte): 
 + 
 +^ Type     ^ Value ^ TX((from sender))^ RX((from receiver)) ^ Info    ^ Data Subpkt    ^ Notes ^ 
 +| ZRQINIT  | 0x00  |  Y               |  -                  | caps    | -              | Request ZRINIT from the receiver | 
 +| ZRINIT   | 0x01  |  -               |  Y                  | caps    | -              | Receiver Initialized | 
 +| ZSINIT   | 0x02  |  Y               |  -                  | flags   | Attn sequence  | Sender Initialized | 
 +| ZACK     | 0x03  |  Y               |  Y                  | offset  | -              | Positive Acknowledgment | 
 +| ZFILE    | 0x04  |  Y               |  -                  | options | File metadata  | File information (name/len/date) | 
 +| ZSKIP    | 0x05  |  -               |  Y                  |         | -              | Skip (don't send) this file | 
 +| ZNAK     | 0x06  |  Y               |  Y                  |         | -              | Negative Acknowledgment | 
 +| ZABORT   | 0x07  |  -               |  Y                  |         | -              | Terminate batch file transfer | 
 +| ZFIN     | 0x08  |  Y               |  -                  |         | -              | Terminate transfer session | 
 +| ZRPOS    | 0x09  |  -               |  Y                  | offset  | -              | Reposition the send offset | 
 +| ZDATA    | 0x0A  |  Y               |  -                  | offset  | File contents  | One or more data subpackets follow | 
 +| ZEOF     | 0x0B  |  Y               |  -                  | offset  | -              | End of file reached | 
 +| ZFERROR  | 0x0C  |  -               |  Y                  |         | -              | File I/O error | 
 +| ZCRC     | 0x0D  |  Y               |  Y                  | CRC-32  | -              | File CRC request/response | 
 +| ZFREECNT | 0x11  |  Y               |  -                  | f-space | -              | Request free disk space | 
 + 
 +**Frame Info**: Up to 15 bytes (but typically 4) of frame type-specific information.\\ 
 +Note that later claims of //16// bytes of possible frame header data include the //Frame Type// byte.
  
 **Frame Header Integrity**: The //Frame Type// and //Frame Info// are integrity-protected with either a 16-bit or 32-bit CRC (determined by the frame encoding). **Frame Header Integrity**: The //Frame Type// and //Frame Info// are integrity-protected with either a 16-bit or 32-bit CRC (determined by the frame encoding).
Line 95: Line 122:
 ==== Data Subpacket ==== ==== Data Subpacket ====
   <data> ZDLE <subpacket type> <crc>   <data> ZDLE <subpacket type> <crc>
- 
-Data Subpackets may contain up to 1024 bytes of //data// (special octet values are transposed and escaped with //ZLDE//). 
  
 **ZDLE** is the ZMODEM Data-link-escape character (''^X'', ASCII 24). **ZDLE** is the ZMODEM Data-link-escape character (''^X'', ASCII 24).
 +
 +=== Data Subpacket Length ===
 +
 +  * Data Subpackets may contain up to **1024** bytes of //data// (special octet values are transposed and escaped with //ZDLE//)
 +  * The Data Subpacket Length is also sometimes referred to as the transmit "block size"
 +  * The Data Subpacket Length can be dynamically adjusted by the sender during the transfer of a file, e.g. in response to errors reported by the receiver
 +  * Some ZMODEM implementations (e.g. "ZedZap") support a Data Subpacket Length of up to 8K (8192 bytes)
  
 === Data Subpacket Types === === Data Subpacket Types ===
 The Data Subpacket Type is encoded in a single byte. The Data Subpacket Type is encoded in a single byte.
  
-^ Type  ^ ZACK/ZRPOS expected ^ End-of-Frame ^ Meaning ^ +^ Type  ^ ZACK/ZRPOS expected ^ End-of-Frame ^ Meaning    ^ Notes ^ 
-| ZCRCW | Yes (synchronous)   | Yes          | Wait    | +| ZCRCW | Yes (synchronous)   | Yes          | Wait or Write | "ZCRCW data subpackets expect a response before the next frame is sent ... to allow the receiver to write its buffer before sending more data"      | 
-| ZCRCE | Only errors         | Yes          | End     | +| ZCRCE | Only errors         | Yes          | End        | "If the end of file is encountered within a frame, the frame is closed with a ZCRCE data subpacket which does not elicit a response except in case of error"     | 
-| ZCRCQ | Yes (asynchronous)  | No           | Query   | +| ZCRCQ | Yes (asynchronous)  | No           | Query      | "ZCRCQ subpackets are not used if the receiver does not indicate full duplex ability with the [ZRINIT] CANFDX bit" | 
-| ZCRCG | Only errors         | No           | Go      |+| ZCRCG | Only errors         | No           | Go         | "ZCRCG subpackets do not elicit a response unless an error is detected"      |
  
 === Data Subpacket Integrity ===   === Data Subpacket Integrity ===  
Line 649: Line 681:
 The pathname (conventionally, the file name) is sent as a The pathname (conventionally, the file name) is sent as a
 null terminated ASCII string.  null terminated ASCII string. 
-No spaces are included in the pathname. +No spaces are included in the pathname. ((some ZMODEM implementations support path/file names that include spaces))
  
 Filename Considerations Filename Considerations

Trace: