Subj : AmiBinkd 2026 To : All From : Gary McCulloch Date : Fri Sep 04 2026 05:51 am 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 (1:154/50) .