• Please review our updated Terms and Rules here

What's wrong with my C# implementation of XMODEM?

Practically speaking, on a hardwired connection, what's the actual difference between Ymodem and Ymodem-G? Modern systems are sufficiently buffered so that disk access is near instantaneous. Have you benchmarked the two, say at 115Kbps full-duplex? I'd be interested in the results. I'm sending my MCU stuff using a hardware CRC computation over a USB connection configured as CDCACM full-speed.

Honestly, I'd like to know--I may convert to Ymodem-G if there's a significant performance improvement. I've tried USB MSD, but there's more overhead than just blasting out packets--and I don't care to expose the filesystem structure.
 
I'm not going to bother benchmarking it, but it's easy enough to do the math to figure out what the added latency is for the ACK packet. 115,000 divided by 10 bit per byte is about 89 microseconds per byte, so it's a small delay.

Go back to typical modem speeds (9600 bps) when Ymodem ruled the earth and you are at 1 millisecond per byte. Xmodem 1K and Ymodem amortized that turn around time by using larger packet sizes, but it was still an interruption. Zmodem use the sliding window and was faster as a result.

While Ymodem G is (marginally) faster, the important thing to remember is that it assumes that something else is doing the error detection and correction. Don't use raw Ymodem G on a phone line ... it has to be used over something like a TCP/IP socket.
 
Oh, you can use Ymodem-G on a phone line, but if your file has an error, you need to retransmit the whole thing again. Were there any protocols that used packets larger than 1K? It's been way too long since I fooled with this stuff. I'm not going to implement Zmodem for a hardwired line--I think the extra code would not make it worthwhile.
 
Well, that's kind of what I meant ... don't use Ymodem G unless you know your connection supports error detection by itself, as Ymodem G doesn't attempt it. Or if you don't love your data, do whatever ...

Personally I wouldn't mess with it either. The 1K packets amortize out the time spent waiting for the ACK packet, and at sufficiently high speeds we are talking about extremely small delays.

If anybody is curious about playing with these things, the mTCP Telnet client supports Xmodem and Ymodem variants. Just connect to a Linux machine and use rz/sz to send and receive files like back in the days of BBSs. (Read the instructions though, as often you have to specify "RAW" mode for the terminal session before starting, or the terminal handler will inject far worse things into the data stream than Telnet does.)
 
Just an update on my progress - I've implemented the XMODEM 128-byte CRC method and a 1K CRC method (in addition to the original 128 checksum method). I've had more success with the 1K CRC approach with the other terminal programs. I'm guessing they just never implemented the original 128-byte packet versions. SyncTERM was interesting in that it mixes 128/1k packets and expects you to handle both.. It makes sense, the last packet if <= 128 bytes is sent using the 128 method. neat. Oh well, on to YMODEM..

I am going to have to try this with the rx,rb,rz / sx,sb,sz commands for compatibility testing.
 
If you're already doing 1K Xmodem, Ymodem is pretty much trivial--mostly the addition of a zero packet. Ymodem can do 128 byte packets as well, but if you're in control and have a fast line, there's nothing to be gained by it. Still, on the receive end, you need to be prepared for them.
 
If you're already doing 1K Xmodem, Ymodem is pretty much trivial--mostly the addition of a zero packet. Ymodem can do 128 byte packets as well, but if you're in control and have a fast line, there's nothing to be gained by it. Still, on the receive end, you need to be prepared for them.
Yep - what are your thoughts on batch? I mean it was part of the protocol so I feel like it should add it (expecting a 0-filled packet to fully end the transfer). However I read many chose not to implement batch, and often it was a separate option called YMODEM-Batch.

EDIT: There are pros and cons to implementing it and just having one "YMODEM". If I do or don't it'll break compatibility with something out there either on the sending or receiving side.. so maybe the most "compatible" solution is to offer it as an option?
 
Last edited:
Back
Top