Talk:XMODEM

From Wikipedia, the free encyclopedia

Comment 12-Feb-2007: I've been looking over references to XMODEM, including the one given in the article, which seems to the primary reference, and while I'm not the appropriate person to MAKE any changes, I'd like to point out that according to Ward Christensen himself (see ref cited in article), XMODEM is a >>RECEIVER DRIVEN<< protocol, exactly the OPPOSITE of what the article states (and, in fact, the opposite of the way it actually works, based at least on the implementation I've been following).

As the article itself points out, INITIALLY it is receiver-driven, and with a little reflection, one can see that it is always receiver-driven, with the one exception that the sender can send <CAN> at any time to abort the transmission (as may happen if no response is obtained within a suitable timeout period, or if the sender wishes to stop a 'taking-too-long' transmission).

One point that most discussions omit (even W.C. only mentions this in passing) is what to do if the packet numbers don't match (after 10 retries - the default, which might also be mentioned). W.C. says this amounts to an irretrieval loss of synchronization, thus the receiver is to send <CAN>. This implies that both the receiver and sender only increment the packet number after an ACK - a very small point, which however is omitted in all the flow diagrams that I have thus far seen. (E.G. <http://www.commonsoftinc.com/Babylon_Cpp/Documentation/Res/KXModemProtocol.htm>)

Another minor (but nevertheless significant) point is that the FIRST packet number is '1', not '0'. After 255 packets the sequence follows 0-255 as stated in the article. This is pointed out in the reference cited. (Extensions of XMODEM use the initial 'Packet 0' to send the finename - clever!)

Javanzee 15:49, 12 February 2007 (UTC)

Sounds to me like your more than qualified to fix it up. Be bold! Maury 23:00, 12 February 2007 (UTC)