Talk:XMODEM

	This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.ComputingWikipedia:WikiProject ComputingTemplate:WikiProject ComputingComputing articles
Low	This article has been rated as Low-importance on the project's importance scale.
	This article is supported by Networking task force (assessed as Mid-importance).

Telecommunications Low‑importance

	Telecommunication portal This article is within the scope of WikiProject Telecommunications, a collaborative effort to improve the coverage of Telecommunications on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.TelecommunicationsWikipedia:WikiProject TelecommunicationsTemplate:WikiProject TelecommunicationsTelecommunications articles
Low	This article has been rated as Low-importance on the project's importance scale.

Untitled

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)[reply]

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

The link at the bottom of the page was broken. I found the appropriate link on textfiles.com and replaced it. Kmwiki (talk) 16:43, 26 November 2008 (UTC)[reply]

Naming of XMODEM

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)[reply]

Xmodem CRC

A specific reviewer keeps changing credit for Xmodem-CRC. Xmodem-CRC was added by Bryan Wilcutt (myself) in the early 80's. It came from a discussion I had with Ward. That is not to say he did not have other conversions regarding the same topic, I have, however, copyrighted an xmodem protocol with 16-bit CRC in the early 80's. Who Ward talked to first is still up in the air, but who made factual claim to the work is indisputable vis-a-vis a copyright versus a letter. —Preceding unsigned comment added by Bwilcutt (talk • contribs) 22:46, 6 July 2010 (UTC)[reply]

See the message I have just left on your talk page regarding this and also your conflict of interest. The source you have cited does not support your claim - it does not even mention XMODEM yet alone XMODEM-CRC, and the source you removed contains a description dated before this entry. In any case copyright does nothing to prove your assertion: it is not a patent - you may implement an existing protocol and legitimately claim copyright on the implementation. That does not make you the creator of the protocol. As I noted on your talk page, I am happy to consider further sources but this is not it. Crispmuncher (talk) 13:51, 7 July 2010 (UTC)[reply]

Bryan, it is not one specific reviewer. I have also reverted your change, and I believe that other experienced Wikipedia editors would do the same given the circumstances (you are replacing two different references that agree, with one link which makes no mention of the topic at hand). As Crispmuncher says, if you have further sources, we'll be happy to figure out how to integrate them into the article. —Mrand ^{Talk • C} 13:05, 8 July 2010 (UTC)[reply]

Crispmuncher, The copyright refers to a Bulletin Board System. It doesn't mention xmodem, compuserve a/b (also supported), message boards, etc. The devil is in the details and you'd have to review a couple of hundred pages of a dead language to see it. Now I know why Academia shuns this system as a reliably referenced resource. I'll be sure to type up a letter, pre-date it, and lay claim to inventing Wikipedia. —Preceding unsigned comment added by 206.169.25.100 (talk) 18:07, 8 July 2010 (UTC)[reply]

Exactly: the source you cite does not even mention XMODEM. How can you use that source to show something that it does not cover? Even if it did it would not be evidence of your assertion - showing that you wrote an implementation of XMODEM-CRC does not show that you created XMODEM-CRC. The same would still hold even with the complete source code.

Your assertion that the date must have been forged is untenable without evidence. There is an earlier version of the same source at [1]. Was that forged too? What about a BBS copy of the original document: [2] - that is quite interesting in that the message preamble shows it was uploaded by Byrns to no less than Ward Christensen's BBS only three days after it was written. It was then downloaded on the 12 February 1985, still before you registered your copyright. Were all those dates forged? If we are applying this level of scrutiny symmetrically we have no concrete evidence that your BBS software even existed before 28 May of that year - that is when you registered your copyright and there is nothing to say that you did not backdate the date of publication when registering it.

I am not suggesting that you did but it is you that disputes the validity of the dates given. I am not even disputing that you may have developed XMODEM-CRC independently based on prior conversations, and could even have been unaware of Byrns's work, but your claim of precedence seems impossible to justify given the evidence available. Crispmuncher (talk) 21:13, 8 July 2010 (UTC)[reply]

"It was downloaded on the 12 February 1985, still before you registered your copyright". Damn. I was hoping you wouldn't noticed I forged my copyright by backdating it, back in 1985, so I could lay claim to the glorious invention of Xmodem-CRC in 2001 (or 2002, have to check the logs). I would have gotten by with it if it wasn't for those meddling kids and their blasted dog. —Preceding unsigned comment added by 24.56.51.209 (talk) 07:30, 9 July 2010 (UTC)[reply]

Single transfer protocol?

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)[reply]

So what happens if the last byte in a file has a value of 26?

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)[reply]

External links modified

Hello fellow Wikipedians,

I have just modified one external link 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 {{Sourcecheck}}).

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 5 June 2024).

If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 16:03, 16 July 2016 (UTC)[reply]

Excessive past tense in article.

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)[reply]