https://gitlab.synchro.net/main/sbbs/-/commit/a84e414a9ae4b712e2d55c54
Modified Files:
src/sbbs3/zmodem.c
Log Message:
Merge branch 'master' of gitlab.synchro.net:main/sbbs
--- SBBSecho 3.37-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/commit/36c17d6b1e4c14b79b0c3ccd
Modified Files:
src/sbbs3/zmodem.c
Log Message:
zmodem: stop stalling a second before the data of every file sent

zmodem_handle_zrpos() purged the receive buffer with a 1-second timeout.
That purge sits on the sender's normal path (every file's first ZRPOS is
just the routine answer to ZFILE), and with nothing to discard, the purge
can only conclude the buffer is empty by letting the read time out. Each
file transferred therefore cost a flat second of silence between its
ZRPOS and its ZDATA, whatever the line speed.

Pass the purge timeout in: 0 for that initial ZRPOS, where anything worth discarding has already arrived, and 1 for the mid-transfer ZRPOS that
follows an error, where waiting briefly for the rest of the receiver's retransmit request is the point.

Sending four files over a pipe took 4.01 seconds before and 0.006 after,
to sexyz and to lrzsz's rz alike.

The purge dates to 76d678710e (sheets-20-lone, 2020-11-28).

Reported by Uwe Ohse, who found it comparing sexyz against lrzsz and
zmtx/zmrx over a simulated 115200 bps line: 5.9 KB/s where the others
managed 10.2 KB/s.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
--- SBBSecho 3.37-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/commit/a8843ffb8b199017665b83fd
Modified Files:
src/sbbs3/zmodem.c
Log Message:
zmodem: don't retransmit the ZFILE at a receiver's opening ZRINIT

A ZMODEM receiver announces itself with a ZRINIT unprompted, and the
sender then sends a ZRQINIT of its own before the first file, drawing a
second ZRINIT. That second one arrives after the ZFILE has already gone
out, and the loop waiting for the ZFILE's answer accepted only ZACK, so a ZRINIT counted as a failed attempt and the whole ZFILE frame was sent
again. The receiver answered both copies, leaving a second ZRPOS on the back-channel that the sender then read mid-stream and treated as a
retransmit request, restarting the file from the beginning and taking two rounds of error recovery to settle. Sending four files to lrzsz cost a
round trip, a duplicate frame and an error in the receiver's log every
session; under load the stale ZRPOS cost seconds.

Absorb one such ZRINIT per ZFILE attempt and keep waiting for the real
answer instead, which is what lrzsz's sender does in the same spot. A
second ZRINIT still retransmits, so a receiver that genuinely missed the
ZFILE recovers as before.

The stale ZRPOS was previously consumed by the 1-second receive-buffer
purge removed in 36c17d6b1e (2026-08-21), which is why the cost was only
the wasted round trip until now. Verified with the sender and receiver
pinned to one CPU, which reproduced the restart in 2 runs of 3 before the change and 0 of 12 after; a 256 MiB send to lrzsz stays at 204 MB/s, and
error recovery under injected bit-flips still completes byte-identical.

Visible in a protocol dump sent by Uwe Ohse, who reported the purge stall.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
--- SBBSecho 3.37-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/commit/09ea8a69012ea2688447f28b
Modified Files:
src/sbbs3/zmodem.c
Log Message:
zmodem: report the receiver's file position instead of always zero

Nearly every message in zmodem.c is prefixed with the current file offset,
but zm->current_file_pos was assigned in exactly one place,
zmodem_send_from(), so on the receiving side it kept the zero that zmodem_init() memset it to. A download therefore ended with
"0 Finishing Session (Sending ZFIN)" printed directly beneath
"8192 Received: ZEOF" -- the latter reads a local position from ftello(),
which is why only some of the numbers looked wrong.

Assign current_file_pos from that same ftello(), at the start of the file
and after each received subpacket, so the two cannot disagree. With a
download stalled after 236504064 bytes, the receiver's timeout message now names that offset rather than 0.

Drop the prefix from the ZFIN message: it ends a session rather than a
file, and has no offset to report in either direction. On the sending side
it had been printing the last file's final position.

zmodem_ver 2.5 -> 2.6.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
--- SBBSecho 3.37-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)