https://gitlab.synchro.net/main/sbbs/-/commit/aaf394a0d833acd89a64d3a9
Modified Files:
docs/v322_new.md src/sbbs3/sexyz.c
Log Message:
sexyz: keep the transmit window >= 4x the block size, like lsz (#1197)

sexyz's -w set only the ZMODEM transmit window and left the block size independent (from -2/-4/-8, default 1 KB), so a window at or below the
block size was configurable -- and it stalled the transfer to roughly one window per second. lsz and Forsberg sz never allow this: when -w is
given they force the block down to a quarter of the window
(blkopt = Txwspac = Txwindow/4), guaranteeing window >= 4*block so the ack-every-quarter-window scheme always has several blocks in flight.

Do the same after argument parsing, so -8 -w8192 and -w8192 -8 both
resolve the same way: floor the window to 256, round to a multiple of 64,
and reduce max_block_size to window/4 when it exceeds it (and the start block_size with it). A one-line notice reports the reduction.

Effect: the formerly-hanging window<=block configurations now complete --
-8 -w8192 reduces the block to 2048 and transfers, -4 -w4096 to 1024,
and so on -- while windows that already left four blocks of headroom
(-w32768 and up with -8) are untouched and unchanged (4.75 and 4.88 MB/s
here, streaming still 11.3). This also makes the divide-by-zero guarded
in 04b47329aa unreachable by configuration, since window/block/4 is now
always >= 1.

This does not make sexyz's windowed throughput competitive with lsz --
at the same block and window sexyz is still many times slower, and very
small windows (which force tiny blocks) remain slow with occasional
one-second stalls. That is the separate sexyz windowed-send overhead
tracked in #1195; this change is only about not permitting the degenerate window<=block configuration that lsz forbids by construction.

sexyz.c version 3.3 -> 3.4. No zmodem.c change, so SyncTERM is
unaffected (it never sets a transmit window anyway).

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/222dbfc7f6fd9921e2754adc
Modified Files:
docs/v322_new.md src/sbbs3/sexyz.c
Log Message:
sexyz: expose the ZMODEM file-management option, and -e for ESCCTL

The engine has carried management_protect / management_clobber / management_newer for years and honors all three in zmodem_send_zfile(),
but nothing ever set them -- not sexyz, not SyncTERM -- so every send
fell through to the default and announced ZF1_ZMCRC ("transfer if
different CRC or length"). The protocol work was already done; only
the plumbing was missing.

Add SendManagement to sexyz.ini's [ZMODEM] section, taking crc (the
default, unchanged), clobber, protect or newer. One enumerated key
rather than three booleans, because the engine treats them as mutually exclusive in a fixed precedence and three independent flags could be
set to a combination that silently resolves to one of them.

On the command line, -p and -n are new and match lsz. -y keeps its
current meaning when receiving -- may we overwrite a file already here
-- and gains the matching one when sending: tell the receiver to
overwrite its own. That is exactly the lrzsz split, where lsz -y sets
ZMCLOB and lrz -y clobbers locally, and -y was previously documented as applying only to receives, so nothing that worked before changes. Note
the two act on different disks: receiving, the destination is this
machine; sending, it is the user's. Synchronet's own receiver ignores
a ZFILE's management field entirely, so this reaches third-party
terminals only.

Also add -e, the command-line equivalent of the existing
EscapeCtrlChars ini key, for links that do not pass control characters
intact. Verified against lrzsz: receiving with -e, the wire grows from 4,312,067 to 5,245,286 bytes for the same 4 MB file, within 0.005 % of
what lrz -e negotiates from the same sender, and verifies
byte-identical. It took the hex-header terminator fix in the preceding
commit to work at all.

When sending, -e is subject to the receiver's ZRINIT, which is what the
engine derives escape_ctrl_chars from, so the usage text says the
receiver's request governs rather than promising something the protocol
layer overrides. Sending with ESCCTL actually negotiated is broken for
a separate, pre-existing reason noted in the preceding commit.

Options parse after the ini is read, so a flag overrides the file;
verified with SendManagement=protect in the ini and -y on the command
line yielding "overwriting destination".

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net