Hacker News Reader

Comment by ape4 | Hacker News Reader

I remember zmodem was slightly better https://en.wikipedia.org/wiki/ZMODEM

ZModem was much better once it was available. You'd generally only use Xmodem after that point if you had no other choice, because it failed frequently over unreliable connections, and all phone line connections were essentially unreliable due to line noise (and sometimes other in-band interruptions). IIRC, ZModem was both faster and resumable, so that if your connection terminated in the middle of your two megabyte transfer you didn't have to redownload the first megabyte.

I remember all kinds of other protocols coming and going. Ymodem-g! Blazing fast. I never had issues with it but friends with worse modems/phone lines were always restarting their transfers.

If I recall, Ymodem-G (as opposed to Ymodem) was basically an unchecksummed raw file dump with a little metadata header, so it was only usable on a connection without line noise. You could actually get undetected file corruption.

Some SysOps would collect and support as many protocols as they could as sort of a form of bragging rights. Even with dozens, almost everyone used zmodem, or once in a while, BiModem if they wanted to chat during a transfer.

zmodem dealt with line noise a lot better, but it seems it was also faster:

    XMODEM used 128-bytes payloads with a three-byte header and one-byte checksum for a total of 132 bytes per packet. In the era of 300 bps modems, a packet took about four seconds to send, and typical latencies were on the order of 1⁄10 of a second, so the performance overhead was not significant. As speeds increase the problem becomes more problematic; at 2400 bps a packet takes about 1⁄2 to send, so about 1⁄5 of the available bandwidth is wasted waiting for ACKs. At 9600 bps a packet requires only 0.13 seconds to send, so about 1⁄2 of the bandwidth is wasted.

    ZMODEM addressed these problems by removing the need for ACKs at all, allowing the sender to send data continually as long as the receiver detected no errors. Only NAKs had to be sent, if and only if there was a problem. Since ZMODEM was often used on links with built-in error correction, like X.25, the receiver would often not send a single message back to the sender. As a result, the system would send the entire file in a continual stream, and ZMODEM referred to itself as a "streaming protocol".

I was a big BBS user (and sysop) from roughly 1988 to 1997 or so. zmodem was much, much faster.

I was just a user so my memory of why I switched to zmodem was a bit suspect. Now that you mention it, there were definitely largish binaries that I could only download with zmodem.

At some point I found a BBS with big files I wanted that only supported ymodem, and after several days of trying and hitting the hour timeout, I gave up.

The other thing that ZMODEM brought to the table, provided your terminal emulator supported it, was automatic downloads. You didn't have to tell the BBS to send FOO.GIF and then turn around and tell your computer to receive FOO.GIF, you just downloaded it with ZMODEM and the download started immediately.

This. So much this.

I had forgotten about that. Super fun when someone sliced a large file into parts and you typed in the wrong thing.

Indeed, at higher speeds it would waste an awful lot of time waiting for ACKs, and that's why XMODEM ACK Spoofing was a feature of higher end (error-correcting, obviously) modems.

They would recognize the protocol, immediately forge ACKs, deal with error correction and retries, and swallow the other side's ACKs when they eventually came.

Truth to be told, by the time this feature was available, many had moved to YMODEM, ZMODEM, BiModem (Bidirectional transfers whoohoo!) and HS/Link (Bidirectional as well, and even chat with the SysOp while transferring data!).

But those spoofing modems were very valuable for environments where the protocol was hardwired and you couldn't update.

Xmodem is the right thing for an embedded target for bringup, but zmodem was tons better for BBS'ing. It performed much better than xmodem. Auto-start in zmodem is wonderful. Multi-file transfers are easy and it even sends the filenames. (My old libraries of BBS downloads, pre-zmodem, are a mess of crappy filenames.)

There has got to be something better than Xmodem for use over a reliable connection. It's not going to be particularly fast.

I guess it depends how "embedded" the target is, I guess. I'd rather write an xmodem implementation in assembler than I would zmodem. I'm envisioning that you're using xmodem to transfer "brain-stem" type firmware where you're talking to a very constrained system. (I know I've sent firmware to Ethernet switch bootloaders via xmodem over serial. Presumably I was very, very close to the metal in that case.)

Exactly. I built my first 8-bit computer after watching Ben Eater's 6502 series and the first thing I did after "Hello! World" was look up what bare minimum serial transfer I could implement that would yell if I fucked up the code in some obvious way (cant check if the data is right on the other end if the RAM is volatile and the transfer code itself is unproven). XModem fit the bill (entire spec on Wikipedia and dumb enough that an assembler beginner can do it).

cat works great over a reliable connection as long as you can get it to start and end in the right places. When the connection is reliable, the only thing that needs doing is delimiting the transfer and possibly sending metadata.

you can't just go all the way from xmodem to zmodem without stopping at ymodem, ymodem 1k and ymodem 1k with batch support first.

also, kermit.

who remembers rip graphics?

I believe I do! Where it'd paint the progress gif or line by line with other formats as it downloaded? You could terminate early if it wasn't what you wanted.

and full blown point and click guis!

of course it was made irrelevant by the fledgling world wide web.

RIP script bombs on BBSes were evil. You could black out someone's screen until they exited and dialed back up.

come to think of it, i don't think there were any private multiline boards in my local toll-free calling area.

it was only packet switched commercial services and shell based internet at the libraries/university.

The only multi-line one I remember vividly was running MajorBBS. The inter-user chat was especially vulnerable to sending RIP commands as it didn't filter them out.

"My user number? Why, 99E99, of course."

> who remembers rip graphics?

Seeing LORD the first time with RIP graphics made me rethink everything I thought I knew about BBS games.

Good memories, beverage on me in the tavern.

RIPscrip from Telegrafix, remember it well. Hit the industry like a tornado at the tail-end before the web overwhelmed everything

Don't forget HS/Link! [1] It was kind of cool being able to chat while the transfer was happening.

1. https://en.wikipedia.org/wiki/HS/Link

HS/Link was invaluable for QWK swapping, especially combined with a {COMMO} auto dialer. I still miss QWK, which was essentially a two-way hybrid of RSS and RFC822.

I see Telix, Qmodem and Procomm mentioned frequently when people reminisce about their modem days but rarely {COMMO} which is a shame. It was a fantastic piece of software which deserves more recognition.

It taught me scripting at age 8. I will be forever grateful. The author passed away ten or twenty years ago, and the family decided not to release the source code, which I will forever be sad about. At least it still runs in emulators.

Not rip graphics, but targa and spectrum 512. Almost lifelike.

zmodem is still very useful as you can use it with ssh

use zssh instead of ssh, then sz on the remote end to send files (and rz to receive)

Is that for some kind of use-case where you can't use SCP?

Absolutely. I used a ton of "sz" when I had a dial-up shell account (and didn't yet know about SLiRP). More recently I've used sz/rz when I've been connected to a router w/ a serial connection and needed to pull down a file from a remote host. The router had an SSH client so I just connected to a Linux box, downloaded my file, then sz'd it to myself over the SSH connection via serial.

works through as many levels of ssh as you want, and much more convenient that having to open another terminal, figure out the cwd and run the command

years ago a load of GUI clients used to have a right click menu to send/receive files that used zmodem (sadly putty wasn't one of them)

Absolutely. On some boards where ethernet is not an option you can still run a serial getty and transfer files to / from the device.

I wrote a zmodem-like protocol many years ago called "sixpack" that worked through anything; I used it through two nested telnet connections going through two terminal servers (serial lines). Sixpack's wire format packs data into six bits, similarly to base64.

This was in 1996. In a fit of amazing fortuitousness, a fellow in Japan, almost exactly at the same time, developed a program called Modemu. It is still out there and has not been maintained since. What Modemu does is creaete a pseudo-tty device in your system that you can use in a program like Minicom. This pseudo-TTY device accepts AT commands to "dial" remote hosts and connect to them.

So at the time I was able to install my Sixpack commands (sps, spr) into Minicom, and then telnet out using Modemu: ATD<host-namne>, then transfer files to the remote hosts.

I would install the receive program by uuencoding it, and then just doing piece by piece copy and paste into the remote session to recover the binary.

> zssh

TIL:

* https://packages.ubuntu.com/search?keywords=zssh

I used it just last week. Thanks to a bad choice regarding kernel modules on Canonical's part I had an update to Ubuntu 22.04 on a Raspberry Pi leave the RPi inaccessible via Ethernet. Luckily I have the serial console on the RPi connected to another co-located device for exactly this potential situation. I was able to ssh to the other device, launch a serial terminal from there to the RPi and transfer the deb file needed to fix the problem directly to the RPi from my laptop via modem.

Reply on news.ycombinator.com