The new 1K packet option
				for
		     Christensen protocol transfers


Why 1k packets?

With the current proliferation of 2400 baud modems, it has become obvious
that throughput (i.e., efficiency) of file transfers could be higher if
more data could be added to the fundamental unit of exchange (i.e., the
"packet").  The reason for this is essentially the "stop and wait" nature
of the Christensen protocol: send a packet, wait for an acknowledgement,
send a packet, wait, etc.  When the packet size is relatively small, as
it has always been with Christensen protocol, this "turn-around" time be-
comes a significant portion of the total time necessary to transfer a file.
If the medium through which the transfer is taking place exhibits its own
delay, the problem is compounded (all transfer media -- even hardwired
RS232 connections -- have some media delay; this delay is much more pro-
nounced in satellite telephone connections and packet-switched networks,
such as Arpanet and Compuserve).

Conversely, using a large packet size with an inherently noisy medium can
not only destroy any gains realized by using a the larger packet, but can
actually increase file transfer time, because retransmission of a large
packet takes longer than retransmission of a small packet.

So it seems logical that any large-packet protocol must also have the
ability to "fall back", in the face of line noise, to the small packets
that are so much more efficient in the noisy environment.

MEX 1.40 implements this fallback feature; it uses nearly the same al-
gorthm employed by Paul Homchick in his 1k-packet modifications to the
public domain XMODEM program (version 10.8 at the time of this writing).
Further, the 1K packet option is entirely user-selectable; if you don't
want to use large packets, simply continue using MEX as you've always
used it; there's no penalty for not using large packets.

If you prefer the higher efficiency (and noisy lines are not a problem
for you), simply append a "K" to the the "T" command when you're SENDING
a file with MEX 1.14.  In fact, you can make this change permanent by
entering the command "GLOBAL K", then using the CLONE command to save
your modified MEX to disk (be advised, however, that if you do this,
you run the risk of not being able to exchange files with versions of
XMODEM or MEX that do not have the 1k packet capability, without expressly
turning off the GLOBAL K).

MEX, when receiving, is always prepared to receive 1k packets, in any
mixture with 128-byte packets.  Thus, when you're preparing MEX to
receive a file, you need take no special action (in fact, the 'K'
option, while accepted, is ignored in a file receive).

MEX, when transmitting, will adjust for line noise; after the third
(not necessarily consecutive) error has occurred, MEX will calculate the
ratio of errors to "virtual" 128-byte packets.  If this ratio exceeds
1 error per each six 128-byte "virtual" packets, MEX will switch to
128-byte mode.  Note that MEX will NOT switch to 128-byte mode until
the next successive packet, however.  Thus, once a packet has started
as a 1k packet, it must finish as a 1k packet (otherwise, certain
combinations of noise could cause the transfer to appear correct,
but be received incorrectly).  If you're using the batch option, MEX
will always switch back to 1k packets at the beginning of the next file.

Note that MEX 1.40 is fully compatible with the emerging YMODEM specif-
ication authored by Chuck Forsberg of Omen Technology, insofar as 1K
blocks are conerned (MEX does not "round up" an outgoing file to 1K,
however -- it switches to 128-byte mode when the remaining outstanding
byte count is less than 1024.  This is permitted by the YMODEM spec-
ification).  

Progress reporting

You'll notice that while transferring files in 1k mode, MEX will print
"logical" record numbers on the screen (actually the starting and end-
ing record numbers of the 1k packet being sent or received).  Note that
this is the 128-byte record number, and bears to relation to the packet
number, which is part of the packet "envelope"; it increments by 1 for
each 1k packet, and is of no consequence to the user.

------------------------------------------------------------