kreme@isis.cs.du.edu (Spam Spam Spam Spam Spam Spam Spam Spam) (03/29/91)
I have been asked to repost this to csa2. We are trying to insure that Andy
receives at least 40 checks on the Zmodem Drivers, so we want to expose the
offer to as many people as possible. I am also cross-posting this to alt.bbs
Please direct all follow ups to csa2.
-----------------
*** File: Zmodem.Finalrpt ***
---------------------
A final summary report concerning Zmodem problems in v2.2 of ProTERM-
specifically, failures to comply with the Zmodem specifications for required
performance features.
This report does not address optional features which should be incorporated
into ProTERM; it focuses on the need to make ProTERM's implementation fully
meet the Zmodem specification on all the required transport level features even
as the optional features are being implemented. It is based on testing that
was done using ProTERM, Zterm, White Knight, MicroPhone II, Telix, and
Turmulator, among others, as test programs in the development of new protocol
drivers for the Washington Apple Pi's TCS [TeleConferences System]. The new
drivers implement all the required and optional features of the Zmodem
specification except CRC32, RLE and LZW compression, and encryption/decryption,
all of which would have required more memory than could be provided on the TCS.
The Zmodem drivers provide a debugging screen display that permits observation
of what the different communication programs are doing as well as what the TCS
is doing. This display and the Zmodem specification docs of Oct. 14, 1988 form
the basis for the observations reported below.
A. SENDING.
1. When sending ProTERM does not respect the buffer size limit specified by
the receiver in ZP0 and ZP1 of its ZRINIT header ... it just keeps sending
without stopping and waiting for the ZACK response to its ZCRCW data subpackets
before continuing. It's as if ProTERM thought ZP0 and ZP1 were both set to 0.
2. When sending ProTERM does not respect the CANFDX bit sent in the ZRINIT
frame. Perhaps the decoding of ZF0 and ZF1 in the frame header is not going
correctly.
3. When sending ProTERM uses ZCRCQ subpackets always where ZCRCW subpackets
should be used. ZCRCQ subpackets should NOT be used, unless the receiver
indicates it has FDX (Full Duplex) capability, which the TCS (on Apple //e's
does not). The TCS drivers do indicate _no_ FDX capability by setting the
CANFDX bit FALSE.
4. When starting a batch send, ProTERM sends multiple ZFILE frames instead of
the standard single ZFILE frame. The number of duplications is equal to the
number of files in the batch. I can't suggest an explanation to point to the
bug for this one, but there is supposed to be only one ZFILE frame preceding
each file.
5. When sending, ProTERM fails to follow the required format of the ZCRCW
subpacket carrying the filename. The ZFILE header is followed by ZCRCW
supacket giving the filename and (optionally) other file info. If the filename
is sent with other file info, it is terminated with a single NUL, but if the
filename alone is sent, the filename should be terminated with a _two(2)_ NULs.
ProTERM terminates the filename with a single NUL though no other information
is sent.
6. ProTERM fails to recognize the 5-CAN sequence to abort the send. (We
actually use 8 CANs followed by 8 BS's as specified in the Zmodem docs, though
just 5 consecutive is - or should be - sufficient to abort the send.)
B. RECEIVING.
1. When receiving ProTERM's Zmodem sends a ZACK header after the _first_ $1900
byte bufferfull; but for every bufferfull after the first it returns a ZRPOS
header that forces the sender BACK $100 bytes. It shouild be sending a ZACK
header if there is no error (there were no errors occurring during these
particular test transfers).
2. We believe that ProTERM does not write its buffer of received data to disk
when downloading via Zmodem -- at least it doesn't do it properly. It should
write the buffer out to disk whenever it gets an error (and must send a ZRPOS)
and also when it receives a ZCRCW (wait) packet. ProTERM behaves as if it may
only write when it gets an error, but at no other time. The indicated buffer
size of $1900 bytes is respected by sending programs, but ProTERM itself should
also protect itself against buffer overflows -- as ProTERM itself could
potentially overflow its buffer and end up putting data into memory
god-knows-where.
3. When receiving, ProTERM does not set the correct file length provided in
the ZFILE frame's ZCRCW subpacket. Instead it pads the file length out to the
next $80-byte boundary.
4. When receiving ProTERM's Zmodem responds to line noise errors incorrectly -
it _just_ sends a ZRPOS header. It should FIRST send the sender's specified
Attn Sequence and _THEN_ the ZRPOS header. It seems that ProTERM may fail to
store the sending program's Attn sequence in response to the ZSINIT frame sent
to it by the TCS as required by the Zmodem specifications.
5. We did try some heavy line noise with ProTERM, but the sending side must
have missed the ZRPOS packet, or it must have been scrambled, because it just
sat waiting for something to come from ProTERM (remember, Zmodem is receiver
driven) to tell it what to do... but nothing ever came.
It appears there is probably another bug to report... that ProTERM doesn't time
out with Zmodem when there's an error on the sender's side and stuff stops
coming in. It should RESEND the ZRPOS packet after timing out (about 10
seconds) to try to force the other side to "wake up").
--
| kreme@nyx.cs.du.edu |The Coven BBS (303) 777 2911 PCP via CODEN Stalr*nk too|
|---------------------|100 Megs of storage. Areas for IBM/MAC/Apple. Games. |
| If you don't get kissed good-night you get Kafka Dreams |