https://gitlab.synchro.net/main/sbbs/-/commit/6033e9d61dad951da5d36309
Modified Files:
docs/v322_new.md exec/load/binkp.js
Log Message:
BinkIT: don't record successful binkp/1.1 callouts as failures

The JSBinkP session loop only breaks out on *receiving* a final M_EOB,
but in binkp/1.1's two-M_EOB handshake the completed state is usually
reached by *sending* the last EOB. After sending it, the peer closes
the connection, and the next loop iteration attempts one more M_EOB on
the now-closed socket; that send fails and (since b795cf6a3d) marked the
whole session as failed -- even though all files had already been sent
and acknowledged. binkit.js then wrote "[callout failure]" to data/binkstats.ini with the sent file(s) listed.

binkp/1.0 peers (Mystic, mbcico) exchange a single M_EOB each and break immediately on receipt, so they were recorded correctly; the bug hit
binkp/1.1 peers (Synchronet/BinkIT, binkd) -- the vast majority of
sessions -- producing huge "failed_callouts" counts despite mail
flowing fine. Reported in DOVE-Net's sync_sysops by Khronos and Gamgee.

Fix: a failed closing M_EOB send is benign once our sent files have all
been acknowledged (pending_ack empty); break the loop without failing
the session in that case. Only fail when files remain unacknowledged.
The on-wire behavior is unchanged. Bumped JSBinkP revision to 6 so the
fix is identifiable via the vers= field in binkstats.ini.

Validated with a two-process TCP loopback harness: binkp/1.1 callout
flips from false to true (file transferred either way); binkp/1.0 and
no-files polls unchanged; a peer that drops mid-transfer still fails.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

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