Talk:XMODEM

message: 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)
replies: text: Sounds to me like your more than qualified to fix it up. Be bold! Maury 23:00, 12 February 2007 (UTC)
thread_title: Untitled

message: There should also be an explanation of the protocol's name, e.g. 'X stands for file transfer', if this was originally meant by the author.
Peterkarl (talk) 08:51, 27 September 2009 (UTC)
thread_title:  Naming of XMODEM 

message: It seems that the main page of this article assumes that the file transfer is expressly controlled by the two users involved (sender and receiver).
Wasn't there another Xmodem protocol that admitted to multiple users, as in a party line situation, where either sender and receiver could opt out, or drop out of the call, and later rejoin, minutes or hours later?   216.99.219.171 (talk) 05:56, 15 August 2010 (UTC)
thread_title:  Single transfer protocol? 

message: If you are supposed to pad an XMODEM packet with ascii character SUB (which has a byte value of 26), and the receiver is supposed to remove this padding, and there is no XMODEM specification for conveying the actual size of the file, then how do you send a file who's last byte (or bytes) have the value 26? Is it simply impossible to transfer such a file with the XMODEM protocol? Or is there some special technique needed to transfer such a file using this protocol?
Animedude5555 (talk) 00:26, 4 December 2013 (UTC)
thread_title:  So what happens if the last byte in a file has a value of 26? 

message: Hello fellow Wikipedians,
I have just modified  on XMODEM. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:
*Added archive https://web.archive.org/web/20121110151951/http://www.techfest.com/hardware/modem/xymodem.htm to http://www.techfest.com/hardware/modem/xymodem.htm
When you have finished reviewing my changes, please set the checked parameter below to true or failed to let others know (documentation at ).
Cheers.—InternetArchiveBot (Report bug) 16:03, 16 July 2016 (UTC)
thread_title:  External links modified 

message: Xmodem is still in current use. It's one of the commonly used methods in embedded systems for flashing boot loader images. In some situations it may be the only available mechanism to recover a "bricked" device. KazKylheku (talk) 18:25, 28 July 2020 (UTC)
thread_title:  Excessive past tense in article.