12 Aug 15 19:42, you wrote to me:

 ML>> those would be the .bsy files in the binkd outbound directories...
 ML>> dependin on the directory for the FTN domain and zone then the decode
 ML>> of the bsy fil name into two sets of hex and emitted as decimal... a
 ML>> bash script should be able to do this pretty easily... at least the
 ML>> zone:net/node numbers... determining the proper FTN domain will be
 ML>> tricky if 4D addressing is used since all will appear to be part of
 ML>> the main outbound domain...

 NA> I keep forgetting about those files... domain-processing I'm not
 NA> really worried about in my particular case as I've got a fairly good
 NA> set of code in place to manipulate the 4D-5D "conversion" when mail is
 NA> moved out of DB into the BinkD FLO format.

going with 5D is the best, really... 4D is ok but everything gets shoved into
the base outbound directory no matter what the base FTN domain is... at that
point, it depends on the configuration of binkd as to what it points to for
each FTN domain's outbound directory tree...

 NA> As a side note, I wonder if the team would be amicable to just adding
 NA> DB's Queue as a supported format internally. That would eliminate a
 NA> HUGE amount of code in the mailer for me... as I'm sure you could
 NA> understand.

true... but it would basically move it from one system to another... they might
be more welcoming if it were provided in a/some patches, though... kinds like
binkleyterm was provided with EMSI and other protocols back in the day... i
remember joho and team providing working code for binkley term back in the
day... code stuffs that weren't really wanted to be added but since it was and
there were so many testers around the network that it kinda pretty much had to
be accepted... i think that janus was the protocol being added at that time but
it has been many years since then...

 NA> But those BSY files do not get periodically updated with tranmission
 NA> rates, sent/received, etc? Thats really what I'm after. Its fine to
 NA> tell a DB user whoes on, but would be better if I could give them a
 NA> sneak-peak of the traffic. Sortof the way that Internet Rex does it,
 NA> graphically in ASCII.

no... there's nothing available from them than the connected address... the
only way to get information like that may be to parse the logs and look at the
reported rates /after/ the transfer is completed... other than that, the only
way i'm aware of would be to access the internal data and that basically means
building binkp capability into dbridge or patching it to provide this data via
some sort of pipe or disk-based files... a pipe would be best outside of having
binkp built in...

 ML>> this paragraph caused me to look and see who i was communicating with
 ML>> :)

 NA> LOL! In a good way I hope! I do my best work after a few beers :)

yes, it was in a good way... at first i thought it was someone else on a *nix
system which is why i posted about a bash script if i left that in my original
post ;)

 ML>> yeah, a bash script wouldn't work but being able to code something in
 ML>> DB shouldn't be much different than DB's own semaphore monitoring and
 ML>> parsing, right?

 NA> Yes, the mailer's semaphore checking code happens every second. Very
 NA> simple to add whatever I want to check... as per above.

on the one hand, that seems rather fast and CPU intensive but i've recently
grown extremely tired of binkd waiting so long before seeing new outbound
traffic so i have been testing with 5s(econd) config entries for the
rescan-delay and call-delay options... all i can say is ""wow!""... it is
almost like running FD again with the very slight delay in seeing what's
needing to go out and making the connection attempt...

 ML>> NA> A shutdown semaphore would be nice; in that if BinkD sees a
 ML>> NA> particular semaphore, it will gracefully shutdown... rather than
 ML>> NA> just being outright "killed" by an OS task maanger or shutdown
 ML>> NA> process.
 ML>> this (and other disk-based semaphores) have been asked for in the
 ML>> past... i wasn't well received... mainly because binkd originates on
 ML>> *nix which used signaling method sending SIGHUP, SIGTERM, SIGKILL and
 ML>> others to the process to cause them to do certain things...

 NA> Thats understandable for *nix, but by the same theory that it is easy
 NA> for me to code semaphore-checking in my mailer, it should also in turn
 NA> be easy to code something that simply checks for that exit-file and
 NA> gracefully shutdown. Its no different of a graceful shutdown than when
 NA> it is ran in "client" mode and quits when its own queue is empty.
 NA> Would be nice of the team to do this for "flavors other than *nix".

exactly... and that's why quite a few of us were pretty disappointed when the
diskbased semaphores were asked for back then... one fellow did endeavore to
provide some things for us but others like the disk based semaphores we asked
for were shot down quite abruptly... there was also something about how
convoluted the code was in certaion areas that lead to problems of
implementation... i have no clue if any of that has been fixed in recent
times... while i do have a repo of the binkd code, i haven't looked to see how
far back it starts and what updates and fixes it contains... at least now i
have a repo (and a system) that i can rebuild on but the repo is only a fork of
what's on github which seems to be updated occasionally by a bot of some
kind...

)\/(ark

... Murphy was an optimist.
-!-
---