AmiBinkD - a native AmigaOS binkd, and how it gets tested ---------------------------------------------------------

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 C-Net/5 and any
other FTN-aware BBS.

The goal is not to write a new mailer. It is to get *binkd itself*
running on the Amiga. 18 of binkd's 34 source files are completely
untouched, and protocol.c - the binkp engine, 3,769 lines - carries
exactly one Amiga-specific line. Where the port does deviate, it is
almost always to work around something broken in the Amiga C library,
not to change how binkd behaves.

TESTING

It runs on a live board carrying seven networks, and that is where
the bugs turn up. Recent examples, all found in production:

* Outbound mail was going out as ZERO BYTES - every bundle, always.
Nothing logged an error, because no layer had one: the tosser
packed a valid archive, and binkd sent exactly the byte count it
was given. The cause was libnix13's fstat(), which always reports
st_size == 0 (it measures with SEEK_CUR right after seeking to the
start). Upstream binkd's code was correct; the C library was not.
Fixed by overriding fstat(). If you build ANY Amiga software with
-mcrt=nix13 and it depends on file sizes, this affects you too.

* Log lines were being torn in half when two sessions wrote at once.
binkd locks its log - but with a private semaphore, which is fine
for one process with threads. This port runs each session as its
own AmigaOS Process, so the lock has to be a PUBLIC semaphore to
span them.

* Concurrent sessions all logged under one id, so three simultaneous
inbound calls read as triplicated lines. Now each has its own.

RELEASES

v10.25 is current and in the file area. v10.29 follows once its soak
is done - by then the fixes are mostly small: quieting a benign lock
race that logged at error level, and removing a diagnostic that
turned out to be reporting garbage.

Nothing ships until it has run on the board for a day or more. A fix
that has not survived a real night of traffic is a guess.

Reign of Fire BBS - call.rofbbs.com - telnet 6800 / ssh call@

* 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)

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)