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 (39:902/518)

Hi Gary,

On 2026-08-19 20:34:32, you wrote to All:

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

Very good work!


Bye, Wilfred.

--- FMail-lnx64 2.3.4.1-B20260520
* Origin: FMail development HQ (39:150/200)

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

I can't tell you how glad I am to see this is being worked on!

|03--|11[|05esc|13!|05dEMONIC|11]|03--|07

--- DayDream BBS/UNIX (Linux) 2.15a
* Origin: [>mONTEREYbBS.COM>] (39:902/552)

There are some small things I am still working on with how this performs under emulation and the .uaem files AmiBerry creates. v10.32 is being released. So there still will be some up-dated release until its 100% error free.

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

Hi wilfred,

On Thursday August 20 2026, Wilfred Van Velzen said to Gary McCulloch:

Hi Gary,

On 2026-08-19 20:34:32, you wrote to All:

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

Very good work!

Why? He didn't create the "no ixemul, no ixnet" version.
Tanausu M did the work, and even announced it back at the end of April 2026.


-- Stephen --

Rocking Amiganet with an Amiga 4000 and Zeus BBS.


--- Zeus BBS 1.5
* Origin: -:-- Dragon's Lair --:- dragon.vk3heg.net Prt: 6800 (39:901/281.0)

Hi Ryan,

On Friday August 21 2026, Ryan Fantus said to Gary McCulloch:

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

I can't tell you how glad I am to see this is being worked on!

Did you forget about fidoblitz? 8-\



-- Stephen --

Rocking Amiganet with an Amiga 4000 and Zeus BBS.


--- Zeus BBS 1.5
* Origin: -:-- Dragon's Lair --:- dragon.vk3heg.net Prt: 6800 (39:901/281.0)

Hi Stephen,

On 2026-08-23 14:50:51, you wrote to me:

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

Very good work!

Why? He didn't create the "no ixemul, no ixnet" version.
Tanausu M did the work, and even announced it back at the end of April

2026.

I didn't realize they were the same version... So cudos to Tanausu too!


Bye, Wilfred.

--- FMail-lnx64 2.3.4.1-B20260520
* Origin: FMail development HQ (39:150/200)

AmiBinkD v10.33 - and where it sits among the other Amiga mailers ------------------------------------------------------------------

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.33 is out. Before the release notes, a word about something that
has come up: AmiBinkD is not the only non-ixemul mailer for the Amiga,
and it was not the first. Worth setting out plainly who has done what,
because three different projects are getting talked about as if they
were the same thing.


WHAT IS ACTUALLY OUT THERE

AmiBinkd v9.02 (2014, X-TReMe BBS)
The original Amiga binkd, and the one people mean when they say
"the old AmiBinkd is buggy". Nothing to do with this project
beyond the name, which I kept because sysops already knew it.
In hindsight that has caused more confusion than it saved.

FidoBlitz (Stephen, v0.19 May 2026)
A native Amiga Binkp/1.1 mailer written in AmiBlitz3. NOT a port
of anything - it is a fresh implementation of the protocol. That
is a different kind of work from what I am doing, and a harder
one in some ways: everything binkd already solved has to be
solved again.

binkd 1.1a-115 noixemul (Ervras, Aminet June 2026)
pgul's binkd adapted to AmigaOS 3.2 without ixemul, built with
bebbo's gcc, requires 68020 or better. Ships extras I do not:
srifreq, process_tic, a nodelist compiler, decompress. His repo
dates from April 2026, so he got a non-ixemul binkd running on
the Amiga before I did. Credit where it is due.

AmiBinkD v10.x (this one)
Also pgul's binkd, also no ixemul. Two differences that matter:

* It builds for plain 68000. No 020 required, no FPU, soft-float
throughout. If you are running a stock A500 or A2000, this is
the one that will start.

* It is deliberately still binkd. 18 of binkd's 34 source files
are untouched, and protocol.c - the binkp engine, 3,769 lines
- carries exactly one Amiga-specific line. Where it does
deviate it is almost always to work around something broken in
the Amiga C library, not to change how binkd behaves.

Two people ported the same program independently without knowing it.
That is how it goes in a hobby this size. Use whichever fits your
machine.


WHAT v10.33 FIXES, AND WHY IT MATTERS TO EVERYONE HERE

For weeks this board had a rare, ugly fault: now and then a write meant
for one file turned up in another. A .bsy lock file was found holding a
line of log text. About 0.2% of log lines - rare enough to look like
cosmic rays, often enough to eventually corrupt something that matters.

Four theories were wrong before the right one. What settled it was a
test that hammered TWO files at once from several Processes. Every
earlier test used a single file and passed cleanly, because with one
file a mixed-up descriptor still resolves to that same file. Two files
and it reproduced in ten seconds: 92 of 1000 log lines lost, and lock
markers written into the log.

The cause is in libnix, not in binkd. Every descriptor comes from
___allocfd, which scans a shared global table for a free slot and grows
it with realloc(), reassigning the global pointer. Disassembling that
layer - open, close, write, read, lseek, fopen, fwrite - there is not
one Forbid/Permit, not one semaphore, nothing atomic anywhere in it.

That is fine for a normal Amiga program. It is not fine if you run more
than one Process, because on AmigaOS they share ONE address space. Two Processes calling open() at the same moment can both take the same
slot. The loser's descriptor now points at the winner's file.

READ THAT AGAIN IF YOU WRITE AMIGA SOFTWARE. It is not a binkd bug and
it is not mine. Anything multi-Process built against libnix has it,
including - I would guess, though I have not tested his build - the
other binkd port above.

v10.33 keeps the heaviest user out of that table. Log() opened and
closed the logfile for EVERY line; it now goes through dos.library
directly and never allocates a descriptor. 4,133 log lines over two
days including outbound transfers, zero corrupted. Lock files and
transfers still use the library's descriptors, so this is not a
complete fix - but those run at a tiny fraction of the frequency.


YOUR PEERS MAY HAVE YOU LOGGED UNDER THE WRONG VERSION

The version was hardcoded in three separate places: the startup line,
the shutdown line, and the VER string sent to every node you poll. Two
got updated over the years and one did not.

From v10.19 to v10.32 every node this system polled recorded it as
v10.19 - including under a release published two days ago. Nothing
local was wrong. Only the REMOTE's log showed it, which is why it went
fourteen versions without anyone noticing. Worth grepping your own
sources for duplicated version literals.


UPGRADING

On v10.23 or earlier: your outbound mail is not being delivered.
Every bundle goes out announced as 0 bytes - libnix13's fstat()
reports st_size as 0 while returning success. Sessions look
completely normal in your log. Fixed in v10.24.

On v10.19 to v10.32: see above, your peers have you as v10.19.

AmiBinkD10_33.lha is in the file area, and on GitHub at
github.com/SpitfireTN/AmiBinkD


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 (39:902/518)

Hi Wilfred,

On Sunday August 23 2026, Wilfred Van Velzen said to Stephen Walsh:

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

Very good work!

Why? He didn't create the "no ixemul, no ixnet" version. Tanausu M did
the work, and even announced it back at the end of April 2026.

I didn't realize they were the same version... So cudos to Tanausu
too!

Yeah, Tanausu started the work, and even has it on github.



-- Stephen --

Rocking Amiganet with an Amiga 4000 and Zeus BBS.


--- Zeus BBS 1.5
* Origin: -:-- Dragon's Lair --:- dragon.vk3heg.net Prt: 6800 (39:901/281.0)

Hi Gary,

On Sunday August 23 2026, Gary McCulloch said to All:

FidoBlitz (Stephen, v0.19 May 2026)
A native Amiga Binkp/1.1 mailer written in AmiBlitz3. NOT a port
of anything - it is a fresh implementation of the protocol. That
is a different kind of work from what I am doing, and a harder
one in some ways: everything binkd already solved has to be
solved again.

Actually Fidoblitz is at 0.21 2026-07-28, and on aminet. Yes it's written
from scratch, but that means there is *Nothing* from other systems to get in they way of how the Amiga does it's thing. It will run on cpu's from the
68000 upto the 68060, there is no requirement for a specific cpu type. It's also been tested on 3.1 though 3.9 to 3.2.3 systems, with both bsdsocket emulation and real tcp/ip stack's (tested on Roadshow, Genesis.)

The version was hardcoded in three separate places: the startup line,
the shutdown line, and the VER string sent to every node you poll. Two got updated over the years and one did not.

Set the version string in one place, and then referance that when needed..

ie:

; Program version string
DEFTYPE.s VERSION
VERSION = "0.21"

; Give our tool a version string including the compile date
!version {"FidoBlitz 0.21 (\\__DATE_GER__)"}

Statement PrintUsage{}
SHARED VERSION
[...]
End Statement



-- Stephen --

Rocking Amiganet with an Amiga 4000 and Zeus BBS.


--- Zeus BBS 1.5
* Origin: -:-- Dragon's Lair --:- dragon.vk3heg.net Prt: 6800 (39:901/281.0)

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)