MEX 1.14 update documentation 20 July 1985 Ron Fowler NightOwl Software, Inc. ------------------------------------------------------------ This is release 1.14 of the MEX Modem EXecutive communications program. This release repairs several bugs reported in version 1.12, and adds support for 1k XMODEM file transfer packets (this modification has also been made to all of the commercial versions of MEX-PC and MexPlus, with release numbers of 1.40 and higher). ------------------------------------------------------------ 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.14 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 1.14 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 1.14, when receiving, is always prepared to receive 1k packets, in any mixture with 128-byte packets. Thus, when you're preparing MEX 1.14 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.14 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", t increments by 1 for each 1k packet, and is of no consequence to the user. ------------------------------------------------------------ Bug fixes for version 1.14: 1) Previously, after opening a terminal file with TERM or TERMA, then issuing a CALL command, the caller would be left at command level rather than in terminal mode when the remote station was reached. This now works as expected. 2) Transferring a file using either Christensen or CIS protocols, with a term file open, would usually garbage the term file. Not any more. 3) Printer-buffering didn't work correctly when the buffer filled. This has been corrected. 4) Long ASCII captures would not be written to disk correctly if the capture buffer was greater than 32K (generally, this only happens in TurboDOS or CPM+ systems, that have large banked TPA's). This has been fixed. ------------------------------------------------------------ Files present in this library: MEX114.COM - The newly released Modem EXecutive -READ114.ME - This information file MEXOVL06.LQT - A list of all known MEX overlays (and a little hype for our commercial versions). (Note that the help file has not been re-issued with this revision). ------------------------------------------------------------