home *** CD-ROM | disk | FTP | other *** search
-
- 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.
-
- ------------------------------------------------------------
-
-