https://gitlab.synchro.net/main/sbbs/-/issues/343#note_4713

It doesn't look like anything has been done yet. I am hopeful that it soon will.

Lately, since binkit is still trying to call out to the nodes whose addresses are set to hold (tickit is creating .flo files instead of .hlo files), and creating .bsy files when it does, the inbound area fills up and tickit doesn't run to process incoming .tic files. After deleting the .bsy file(s), tickit will run as it should. Before it does, I append the corresponding .flo to the .hlo file manually.

Not being a programmer, I have no idea where to look in the code to attempt to repair it. I am hopeful that someone who can, will correct this. In the meantime, I will have to return to Husky's htick. I like that binkit, tickit, etc., are all integrated and requires fewer configuration files.

Thanks!!
--- SBBSecho 3.20-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/issues/343#note_4727

FWIW: binkit is doing right when it tries to deliver flo, clo, and dlo files to a remote set as hold... binkd does the same... this allows binkit/binkd to deliver some mail while the remote node has to connect inbound to pick up whatever traffic is waiting on hold... for example, maybe you don't want to deliver some huge file(s) but you still want to deliver mail...

the fix to create or append to existing hlo (and dlo or clo) file(s) is needed in tickit... i thought i saw a commit long ago from someone else that did fix it but i cannot locate that commit... i've been thinking for the last months that i needed to find it and backport it to my old pre-git version... with all the changes since the last time i updated before the move to git, i don't know if routine(s) to look that up exist, if they are the same as they were, or need to be created...

in any case, a quick look at my copy of the old code shows that at the end of "function forward_tic(tic)" flo is assumed and no lookup for flo type is done at all... look for comment "// Append to FLO file..."...

there probably should also be a timeout abort just higher in the "// Create bsy file..." section... especially if multiple tickits are being fired and running at the same time... looks like a possible race condition with other instances and may be where your multiple bsy files are coming from... perhaps tickit should maintain a "running" semaphore so only one instance can be executed at a time? idk and it has been too long...
--- SBBSecho 3.20-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/issues/343#note_7394

Hi all! I still have too many call out's from binkit for downlinks nodes.
I know that is not problem.. But they are wasting meaningless resources, including filling up the binkit log with noise that these nodes would never connect to.
binkit should never call nodes that are not marked for polling
--- SBBSecho 3.28-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

Fernando Toledo wrote to GitLab note in main/sbbs <=-

https://gitlab.synchro.net/main/sbbs/-/issues/343#note_7394

Hi all! I still have too many call out's from binkit for downlinks
nodes. I know that is not problem.. But they are wasting meaningless resources, including filling up the binkit log with noise that these
nodes would never connect to. binkit should never call nodes that are
not marked for polling

It's not so much a binkit issue as it is a tickit issue... I read your
issue at the link above and can also confirm that this is still
happening. In fact you can have a downlink on "Pause" (their connected
link section has "Passive = true" in it), and Tickit will still create
.dlo files to send them the file referenced in an incoming .TIC.

There are a couple of other bugs/feature requests pending for Tickit
also... Hopefully some attention soon! :-)



... I was wondering why the baseball was getting bigger. Then it hit me.
--- MultiMail/Linux v0.52
þ Synchronet þ Palantir BBS * palantirbbs.ddns.net * Pensacola, FL
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)