AmiBinkD v10.35 - polls that do not stall ------------------------------------------------------------------
AmiBinkD is a port of binkd to AmigaOS 3.x. It talks straight to bsdsocket.library - no ixemul, no ixnet - and runs on real 68k iron
or under emulation. BinkP/1.1, CRAM-MD5, works with any FTN-aware
Amiga BBS.
v10.35 is one fix, and it is worth taking if you poll on a schedule.
POLLS NO LONGER STALL PARTWAY THROUGH
A poll could stop dead in the middle of a session and stay stopped
for anything from ten minutes to two hours. It ended only when the
node at the far end gave up waiting. The process stayed alive the
whole time and the log simply went quiet, so there was nothing in it
to point at a cause.
If your BBS runs its polls from an event scheduler - C-Net/5 does -
this was worse than a lost poll, because a session that will not
finish holds the scheduler with it. Here, on 30 August, a stalled
13:30 poll took the local console login down too and the machine had
to be restarted to get it back.
The cause was AmiBinkD doing housekeeping on its own lock. Partway
through every handshake it scans the outbound queue, and that scan
tidies away stale .bsy and .csy lock files. The locks it looks at
belong to the node at the other end of the call - which during a
live session is exactly the node whose lock that session created
when it dialled. It was finding its own lock, deciding it looked
old, and going to the filesystem to deal with it while the session
sat there on an unread socket.
What gave it away was that the stalls were as long as kill_old_bsy
told them to be: about two hours while that was set to 2h, then
about fifteen minutes, three times running, once it was lowered to
15m.
A lock a running session is holding is by definition not stale, so
there is nothing there to clean up. It is now skipped without
touching the filesystem at all.
Measured here: nine stalls in 243 scans over the three days before
the fix. Across the five days after it, thirty-six polls began and
thirty-six ended.
NOTHING TO CONFIGURE
kill_old_bsy keeps whatever value you have given it. It now applies
only to locks that no running session owns, which is what it was
always meant to mean.
UPGRADING
Drop in the new binary. No config changes, and nothing in the
protocol or transfer path changed.
One thing worth knowing if you run the mailer as a resident inbound
listener started once at boot: replacing the binary does not update
it. Scheduled polls exec a fresh copy each cycle and pick the new
build up immediately, but the listener keeps the old code until it
is restarted. Until then the nodes you call see v10.35 and the nodes
that call you see the old one.
The source has been public throughout, and is at
https://github.com/SpitfireTN/AmiBinkD
with every release tagged, so v10.35 is the exact tree the binary in
this archive was built from.
Reign of Fire BBS - rofbbs.com - call.rofbbs.com
* ACIS Member. AmigaNet ArakNet C=Net DescipleNet FidoNet PiNet RetroNet
* C-Net/5
* Origin: call.rofbbs.com : 6800 6400 8502 : 423-541-8271 : rofbbs.com (39:902/518)