zmtx-new.c

这是G.723和G.729的音频编解码的源代码

//
//	Multiple files may be transferred in one session.
//
//SAMPLE
//------
//
//	all zmodem transactions are done using frames. a frame consists
//	of a header followed by one or more data subpackets.
//	a typical (simple) zmodem file transfer looks like this :
//
//	    sender                      receiver
//
//		ZRQINIT(0)
//							        ZRINIT
//		ZFILE
//							        ZRPOS
//		ZDATA data ...
//		ZEOF
//							        ZRINIT
//		ZFIN
//							        ZFIN
//		OO
//
//	zmodem continuously	transmits data unless the receiver interrupts
//	the sender to request retransmission of garbled data.
//	zmodem in effect uses the entire file as a window.
//
//REQUIREMENTS
//------------
//
//	zmodem requires an 8 bit transfer medium; but allows encoded packets
//	for less transparent media.
//	zmodem escapes network control characters to allow operation with
//	packet switched networks.
//
//	To support full streaming, the transmission path should either assert
//	flow control or pass full speed transmission without loss of data.
//	Otherwise the zmodem sender must manage the window size.
//
//	zmodem places no constraints on the content files.
//
//LINK ESCAPE ENCODING
//--------------------
//
//	zmodem achieves data transparency by extending the 8 bit character set
//	(256 codes) with escape sequences based on the zmodem data link escape
//	character ZDLE
//
//	Link Escape coding permits variable length data subpackets without the
//	overhead of a separate byte count.  It allows the beginning of frames to
//	be detected without special timing techniques, facilitating rapid error
//	recovery.
//
//	Link Escape coding does add some overhead.  The worst case, a file
//	consisting entirely of escaped characters, would incur a 50% overhead.
//
//	The ZDLE character is special. ZDLE represents a control
//	sequence of some sort. If a ZDLE character appears in binary data,
//	it is prefixed with ZDLE, then sent as ZDLEE
//
//	5 consecutive CAN characters abort a zmodem session
//
//	Since CAN is not used in normal terminal operations, interactive
//	applications and communications programs can monitor the data flow for
//	ZDLE.  The following characters can be scanned to detect the ZRQINIT
//	header, the invitation to automatically download commands or files.
//
//	Receipt of five successive CAN characters will abort a zmodem session.
//	Eight CAN characters are sent (just to be on the safe side)
//
//	The receiving program decodes any sequence of ZDLE followed by a byte with
//	bit 6 set and bit 5 reset (upper case letter, either parity) to the
//	equivalent control character by inverting bit 6.  This allows the
//	transmitter to escape any control character that cannot be sent by the
//	communications medium. In addition, the receiver recognizes escapes for
//	0x7f and 0xff should these characters need to be escaped.
//
//	zmodem software escapes ZDLE (0x18), 0x10, 0x90, 0x11, 0x91, 0x13,
//	and 0x93. 
//	If preceded by 0x40 or 0xc0 (@), 0x0d and 0x8d are also escaped to
//	protect the Telenet command escape CR-@-CR. The receiver ignores
//	0x11, 0x91, 0x13, and 0x93 characters in the data stream.
//
//HEADERS
//-------
//
//	All zmodem frames begin with a header which may be sent in binary or HEX
//	form. Either form of the header contains the same raw information:
//
//	- A type byte
//
//	- Four bytes of data indicating flags and/or numeric quantities depending
//	  on the frame type
//
//	the maximum header information length is 16 bytes
//	the data subpackets following the header are maximum 1024 bytes long.
//
//             M         L
//      FTYPE  F3 F2 F1 F0   (flags frame)
//
//             L         M
//      FTYPE  P0 P1 P2 P3   (numeric frame)
//
//    Beware of the catch; flags and numbers are indexed the other way around !
//
//	16 BIT CRC BINARY HEADER
//	------------------------
//	
//		A binary header is sent by the sending program to the receiving
//		program. All bytes in a binary header are ZDLE encoded.
//	
//		A binary header begins with the sequence ZPAD, ZDLE, ZBIN.
//	
//		0 or more binary data subpackets with 16 bit CRC will follow depending
//		on the frame type.
//	
//		* ZDLE A TYPE F3/P0 F2/P1 F1/P2 F0/P3 CRC-1 CRC-2
//	
//	
//	32 BIT CRC BINARY HEADER
//	------------------------
//	
//		A "32 bit CRC" Binary header is similar to a Binary Header, except the
//		ZBIN (A) character is replaced by a ZBIN32 (C) character, and four
//		characters of CRC are sent.
//	
//		0 or more binary data subpackets with 32 bit CRC will follow depending
//		on the frame type.
//	
//		* ZDLE C TYPE F3/P0 F2/P1 F1/P2 F0/P3 CRC-1 CRC-2 CRC-3 CRC-4
//	
//	HEX HEADER
//	----------
//	
//		The receiver sends responses in hex headers.  The sender also uses hex
//		headers when they are not followed by binary data subpackets.
//	
//		Hex encoding protects the reverse channel from random control 
//		characters. The hex header receiving routine ignores parity.
//	
//		use of hex headers by the receiving program allows control characters
//		to be used to interrupt the sender when errors are detected.
//		A HEX header may be used in place of a binary header
//		wherever convenient.
//		If a data packet follows a HEX header, it is protected with CRC-16.
//	
//		A hex header begins with the sequence ZPAD, ZPAD, ZDLE, ZHEX.  
//		The extra ZPAD character allows the sending program to detect
//		an asynchronous header (indicating an error condition) and then
//		get the rest of the header with a non-error specific routine.
//	
//		The type byte, the four position/flag bytes, and the 16 bit CRC
//		thereof are sent in hex using the character set 01234567890abcdef.
//		Upper case hex digits are not allowed.
//		Since this form of hex encoding detects many patterns of errors,
//		especially missing characters, a hex header with 32 bit CRC has not
//		been defined.
//	
//		A carriage return and line feed are sent with HEX headers.  The
//		receive routine expects to see at least one of these characters, two
//		if the first is CR.
//	
//		An XON character is appended to all HEX packets except ZACK and ZFIN.
//		The XON releases the sender from spurious XOFF flow control characters
//		generated by line noise. XON is not sent after ZACK headers to protect
//		flow control in streaming situations. XON is not sent after a ZFIN
//		header to allow proper session cleanup.
//	
//		0 or more data subpackets will follow depending on the frame type.
//	
//		* * ZDLE B TYPE F3/P0 F2/P1 F1/P2 F0/P3 CRC-1 CRC-2 CR LF XON
//	
//		(TYPE, F3...F0, CRC-1, and CRC-2 are each sent as two hex digits.)
//	
//	BINARY DATA SUBPACKETS
//	----------------------
//	
//		Binary data subpackets immediately follow the associated binary header
//		packet.  A binary data packet contains 0 to 1024 bytes of data.
//		Recommended length values are 256 bytes below 2400 bps, 512 at 
//		2400 bps, and 1024 above 4800 bps or when the data link is known to
//		be relatively error free.
//	
//		No padding is used with binary data subpackets.  The data bytes are
//		ZDLE encoded and transmitted.  A ZDLE and frameend are then sent,
//		followed by two or four ZDLE encoded CRC bytes.  The CRC accumulates
//		the data bytes and frameend.
//	
//PROTOCOL TRANSACTION OVERVIEW
//-----------------------------	
//
//	zmodem timing is receiver driven.  The
//	transmitter should not time out at all, except to abort the program if no
//	headers are received for an extended period of time, say one minute.
//	
//	SESSION STARTUP
//	---------------
//
//		To start a zmodem file transfer session, the sending program is called
//		with the names of the desired file(s) and option(s).
//	
//		Then the sender may send a ZRQINIT header. The ZRQINIT header causes a
//		previously started receive program to send its ZRINIT header without
//		delay.
//	
//		In an interactive or conversational mode, the receiving application
//		may monitor the data stream for ZDLE.  The following characters may be 
//		scanned for B00 indicating a ZRQINIT header, a command to download
//		data.
//	
//		The sending program awaits a command from the receiving program to
//		start file transfers. 
//	
//		In case of garbled data, the sending program can repeat the invitation
//		to receive a number of times until a session starts.
//	
//		When the zmodem receive program starts, it immediately sends a ZRINIT
//		header to initiate zmodem file transfers, or a ZCHALLENGE header to
//		verify the sending program.  The receive program resends its header at
//		response time (default 10 second) intervals for a suitable period of
//		time (40 seconds total) before exitting.
//	
//		If the receiving program receives a ZRQINIT header, it resends the
//		ZRINIT header.  If the sending program receives the ZCHALLENGE header,
//		it places the data in ZP0...ZP3 in an answering ZACK header.
//	
//		If the receiving program receives a ZRINIT header, it is an echo
//		indicating that the sending program is not operational.
//	
//		Eventually the sending program correctly receives the ZRINIT header.
//	
//		The sender may then send an optional ZSINIT frame to define the
//		receiving program's Attn sequence, or to specify complete control
//		character escaping. if the receiver specifies the same or higher
//		level of escaping the ZSINIT frame need not be sent unless an Attn
//		sequence is needed.
//	
//		If the ZSINIT header specifies ESCCTL or ESC8, a HEX header is used,
//		and the receiver activates the specified ESC modes before reading the
//		following data subpacket.
//	
//		The receiver sends a ZACK header in response, containing 0.
//	
//	FILE TRANSMISSION
//	-----------------
//
//		The sender then sends a ZFILE header with zmodem Conversion,
//		Management, and Transport options (see ZFILE header type) followed
//		by a ZCRCW data subpacket containing the file name, file length and
//		modification date.
//
//		The receiver examines the file name, length, and date information
//		provided by the sender in the context of the specified transfer
//		options, the current state of its file system(s), and local security
//		requirements.  The receiving program should insure the pathname and
//		options are compatible with its operating environment and local
//		security requirements.
//
//		The receiver may respond with a ZSKIP header, which makes the sender
//		proceed to the next file (if any) in the batch.
//
//			The receiver has a file with the same name and length, may
//			respond with a ZCRC header with a byte count, which
//			requires the sender to perform a 32 bit CRC on the
//			specified number of bytes in the file and transmit the
//			complement of the CRC in an answering ZCRC header.the crc is
//			initialised to 0xfffffff; a byte count of 0 implies the entire
//			file the receiver uses this information to determine whether to
//			accept the file or skip it.  This sequence may be triggered
//			by the ZMCRC Management Option.
//
//		A ZRPOS header from the receiver initiates transmission of the file
//		data starting at the offset in the file specified in the ZRPOS header.
//		Normally the receiver specifies the data transfer to begin begin at
//		offset 0 in the file.
//
//			The receiver may start the transfer further down in the
//			file.  This allows a file transfer interrupted by a loss
//			of carrier or system crash to be completed on the next
//			connection without requiring the entire file to be
//			retransmitted. If downloading a file from a timesharing
//			system that becomes sluggish, the transfer can be
//			interrupted and resumed later with no loss of data.
//
//		The sender sends a ZDATA binary header (with file position) followed
//		by one or more data subpackets.
//	
//		The receiver compares the file position in the ZDATA header with the
//		number of characters successfully received to the file. If they do not
//		agree, a ZRPOS error response is generated to force the sender to the
//		right position within the file. (if the ZMSPARS option is used the
//		receiver instead seeks to the position given in the ZDATA header)
//
//		A data subpacket terminated by ZCRCG and CRC does not elicit a
//		response unless an error is detected; more data subpacket(s) follow
//		immediately.
//
//		ZCRCQ data subpackets expect a ZACK response with the
//		receiver's file offset if no error, otherwise a ZRPOS
//		response with the last good file offset.  Another data
//		subpacket continues immediately.  ZCRCQ subpackets are
//		not used if the receiver does not indicate full duplex ability
//		with the CANFDX bit.
//
//		ZCRCW data subpackets expect a response before the next frame is sent.
//		If the receiver does not indicate overlapped I/O capability with the
//		CANOVIO bit, or sets a buffer size, the sender uses the ZCRCW to allow
//		the receiver to write its buffer before sending more data.
//
//			A zero length data frame may be used as an idle
//			subpacket to prevent the receiver from timing out in
//			case data is not immediately available to the sender.
//
//		In the absence of fatal error, the sender eventually encounters end of
//		file.  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.
//
//		The sender sends a ZEOF header with the file ending offset equal to
//		the number of characters in the file.  The receiver compares this
//		number with the number of characters received. If the receiver has
//		received all of the file, it closes the file.  If the file close was
//		satisfactory, the receiver responds with ZRINIT.  If the receiver has
//		not received all the bytes of the file, the receiver ignores the ZEOF
//		because a new ZDATA is coming. If the receiver cannot properly close
//		the file, a ZFERR header is sent.
//
//		After all files are processed, any further protocol
//		errors should not prevent the sending program from
//		returning with a success status.
//
//	SESSION CLEANUP
//	---------------
//
//		The sender closes the session with a ZFIN header.  The receiver
//		acknowledges this with its own ZFIN header.
//
//		When the sender receives the acknowledging header, it sends two
//		characters, "OO" (Over and Out) and exits.
//		The receiver waits briefly for the "O" characters, then exits
//		whether they were received or not.
//
//	SESSION ABORT SEQUENCE
//	----------------------
//
//		If the receiver is receiving data in streaming mode, the Attn
//		sequence is executed to interrupt data transmission before the Cancel
//		sequence is sent.  The Cancel sequence consists of eight CAN
//		characters and ten backspace characters.  zmodem only requires five
//		Cancel characters, the other three are "insurance".
//
//		The trailing backspace characters attempt to erase the effects of the
//		CAN characters if they are received by a command interpreter.
//
//	       char ses_abort_seq[] = {
//				24,24,24,24,24,24,24,24,8,8,8,8,8,8,8,8,8,8,0
//	       };
//
//	ATTENTION SEQUENCE
//	------------------
//
//		The receiving program sends the Attn sequence whenever it detects an
//		error and needs to interrupt the sending program.
//
//		The default Attn string value is empty (no Attn sequence).  The
//		receiving program resets Attn to the empty default before each
//		transfer session.
//
//		The sender specifies the Attn sequence in its optional ZSINIT frame.
//		The Attn string is terminated with a null.
//
//FRAME TYPES
//-----------
//
//	The numeric values are listed at the end of this file.
//	Unused bits and unused bytes in the header (ZP0...ZP3) are set to 0.
//
//	ZRQINIT
//	-------
//
//		Sent by the sending program, to trigger the receiving program to send
//		its ZRINIT header.  
//		The sending program may
//		repeat the receive invitation (including ZRQINIT) if a response is
//		not obtained at first.
//
//		ZF0 contains ZCOMMAND if the program is attempting to send a command,
//		0 otherwise.
//
//	ZRINIT
//	------
//
//		Sent by the receiving program. ZF0 and ZF1 contain the  bitwise or
//		of the receiver capability flags:
//
//			CANCRY		receiver can decrypt
//			CANFDX		receiver can send and receive true full duplex
//			CANOVIO		receiver can receive data during disk I/O
//			CANBRK		receiver can send a break signal
//			CANCRY		receiver can decrypt
//			CANLZW		receiver can uncompress
//			CANFC32		receiver can use 32 bit Frame Check
//			ESCCTL		receiver expects ctl chars to be escaped
//			ESC8		receiver expects 8th bit to be escaped
//
//		ZP0 and ZP1 contain the size of the receiver's buffer in bytes, or 0
//		if nonstop I/O is allowed.
//
//		while all these capabilities are nice in theory most zmodem implem-
//		tations balk at anything other than 0,0. i.e. telix starts sending
//		35 byte packets when CANFC32 is on.
//
//	ZSINIT
//	------
//
//		The Sender sends flags followed by a binary data subpacket terminated
//		with ZCRCW.
//
//			TESCCTL		Transmitter expects ctl chars to be escaped
//			TESC8		Transmitter expects 8th bit to be escaped
//
//		The data subpacket contains the null terminated Attn sequence,
//		maximum length 32 bytes including the terminating null.
//
//	ZACK
//	----
//
//		Acknowledgment to a ZSINIT frame, ZCHALLENGE header, ZCRCQ or ZCRCW
//		data subpacket.  ZP0 to ZP3 contain file offset.  The response to
//		ZCHALLENGE contains the same 32 bit number received in the ZCHALLENGE
//		header.
//
//	ZFILE
//	-----
//		This frame denotes the beginning of a file transmission attempt.
//		ZF0, ZF1, and ZF2 may contain options. A value of 0 in each of these
//		bytes implies no special treatment.  Options specified to the
//		receiver override options specified to the sender with the exception
//		of ZCBIN.  A ZCBIN from the sender overrides any other Conversion
//		Option given to the receiver except ZCRESUM.  A ZCBIN from the
//		receiver overrides any other Conversion Option sent by the sender.
//
//
//		ZF0: CONVERSION OPTION
//		----------------------
//
//			If the receiver does not recognize the Conversion Option, an
//			application dependent default conversion may apply.
//
//			ZCBIN "Binary" transfer - inhibit conversion unconditionally
//
//			ZCNL Convert received end of line to local end of line
//			     convention.  The supported end of line conventions are
//			     CR/LF (most ASCII based operating systems except Unix
//			     and Macintosh), and NL (Unix).  Either of these two end
//			     of line conventions meet the permissible ASCII
//			     definitions for Carriage Return and Line Feed/New Line.
//			     Neither the ASCII code nor zmodem ZCNL encompass lines
//			     separated only by carriage returns.  Other processing
//			     appropriate to ASCII text files and the local operating
//			     system may also be applied by the receiver. (filtering
//			     RUBOUT NULL Ctrl-Z etc)
//
//			ZCRECOV Recover/Resume interrupted file transfer.  ZCREVOV is
//			     also useful for updating a remote copy of a file that
//			     grows without resending of old data.  If the destination
//			     file exists and is no longer than the source, append to
//			     the destination file and start transfer at the offset
//			     corresponding to the receiver's end of file.  This
//			     option does not apply if the source file is shorter.
//			     Files that have been converted (e.g., ZCNL) or subject
//			     to a single ended Transport Option