Questions regarding Zmodem download/upload reliability for linux hosts on both ends
Hi, in my recent testing zmodem-streaming
between git.synchro.net
and my Debian 12 linux powered by lrzsz+zssh failed after transferring few files (check attachment-1, it just messed up the whole screen). Luckily zmodem-windowed
didn't fail (I have tested only once though). -windowed
did print error message (Retry 0: Got ERROR
), but I am not sure if that's false alarm from rz command on client side (check attachment-2).
Sexyz wiki section on streaming mentions that "SEXYZ supports the following ZMODEM streaming modes, in order of decreasing successful data transfer assurance". Does that apply also apply to connections between Synchronet BBS server talking to a Linux/Windows machine running programs like rz
over zssh/ztelnet, or just when Synchronet is connected to a old-style modem? (am pretty new to BBSing, please pardon my lack of understanding).
The reason I ask is: I want to setup a BBS for modern Linux geeks, and would want to provide only the most reliable download experience (as in our times it is unheard of to have download/upload failures). Is unreliability indispensable when communicating over zmodem protocol between Linux remote server and client? Does synchronet plan to support sftp for downloads? Is there a recommended streaming mode that linux clients powered by zssh+lrzsz use when dealing with downloads/uploads? One thing that would really help is to document expected/mandatory flags for rz
and sz
commands for all the respective streaming modes. IMHO, newbies from Linux land like me who are new to BBSing do not really understand if/when to pass any flags when talking to BBS servers. Here's the Debian documentation for lrzrz's rz and sz commands. Would having sexyz on both client and server improve reliability? For such a setting (where both sides are sexyz), could sexyz support a modern or exclusive-to-sexyz file transfer protocol that would ensure 100% reliability? That would be a welcome addition among groups who don't want to think much about reliability in our times.