10 ms·

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

by ape4 4y ago

blibble 4y ago
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)
- outworlder 4y ago
  Is that for some kind of use-case where you can't use SCP?
  - EvanAnderson 4y ago
    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.
  - blibble 4y ago
    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)
  - fullstop 4y ago
    Absolutely. On some boards where ethernet is not an option you can still run a serial getty and transfer files to / from the device.
- kazinator 4y ago
  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.
- throw0101a 4y ago
  > zssh TIL: * https://packages.ubuntu.com/search?keywords=zssh https://packages.ubuntu.com/search?keywords=zssh
- tssva 4y ago
  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.
hinkley 4y ago
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".
- icedchai 4y ago
  I was a big BBS user (and sysop) from roughly 1988 to 1997 or so. zmodem was much, much faster.
  - hinkley 4y ago
    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.
- flyinghamster 4y ago
  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.
EvanAnderson 4y ago
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.)
- KerrAvon 4y ago
  There has got to be something better than Xmodem for use over a reliable connection. It's not going to be particularly fast.
  - EvanAnderson 4y ago
    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.)
    - boondaburrah 4y ago
      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).
  - amluto 4y ago
    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.
KerrAvon 4y ago
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.
- deleted 4y ago
  [deleted]
- bluedino 4y ago
  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.
  - ericbarrett 4y ago
    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.
  - Mountain_Skies 4y ago
    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.
a-dub 4y ago
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?
- thedougd 4y ago
  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.
  - a-dub 4y ago
    and full blown point and click guis! of course it was made irrelevant by the fledgling world wide web.
    - mmastrac 4y ago
      RIP script bombs on BBSes were evil. You could black out someone's screen until they exited and dialed back up.
      - a-dub 4y ago
        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.
        mmastrac 4y ago
        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.
      - CamperBob2 4y ago
        "My user number? Why, 99E99, of course."

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

by ape4 4y ago

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

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)

outworlder 4y ago
Is that for some kind of use-case where you can't use SCP?
- EvanAnderson 4y ago
  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.
- blibble 4y ago
  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)
- fullstop 4y ago
  Absolutely. On some boards where ethernet is not an option you can still run a serial getty and transfer files to / from the device.
kazinator 4y ago
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.
throw0101a 4y ago
> zssh TIL: * https://packages.ubuntu.com/search?keywords=zssh https://packages.ubuntu.com/search?keywords=zssh
tssva 4y ago
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.

hinkley 4y ago

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".

icedchai 4y ago
I was a big BBS user (and sysop) from roughly 1988 to 1997 or so. zmodem was much, much faster.
- hinkley 4y ago
  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.
flyinghamster 4y ago
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.

EvanAnderson 4y ago

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.)

KerrAvon 4y ago
There has got to be something better than Xmodem for use over a reliable connection. It's not going to be particularly fast.
- EvanAnderson 4y ago
  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.)
  - boondaburrah 4y ago
    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).
- amluto 4y ago
  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.

KerrAvon 4y ago

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.

deleted 4y ago
[deleted]
bluedino 4y ago
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.
- ericbarrett 4y ago
  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.
- Mountain_Skies 4y ago
  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.

a-dub 4y ago

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?

thedougd 4y ago
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.
- a-dub 4y ago
  and full blown point and click guis! of course it was made irrelevant by the fledgling world wide web.
  - mmastrac 4y ago
    RIP script bombs on BBSes were evil. You could black out someone's screen until they exited and dialed back up.
    - a-dub 4y ago
      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.
      - mmastrac 4y ago
        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.
    - CamperBob2 4y ago
      "My user number? Why, 99E99, of course."