Hello, All.

I've set up BinkleyTerm to answer the first (and currently only) telnet node on
my BBS. So if any of you that have BT set up for telnet, give it a try by crashing me a netmail or something. :) I don't know how to get BT to dial out yet on telnet, but I'll work on it.

Later,
Sean

//sean@nsbbs.info | http://nsbbs.info | ICQ: 19965647

... Does the name Pavlov ring a bell?
--- GoldED/2 3.0.1
* Origin: Nocturnal State BBS - Johnson City, TN - bbs.nsbbs.info (1:18/200)

I've set up BinkleyTerm to answer the first (and currently only)
telnet node on my BBS.

can i/we assume that this is on the standard telnet port or do we need to do something special and specify an alternative port??

So if any of you that have BT set up for telnet, give it a try by crashing me a netmail or something. :)

well, i don't run binkleyterm but i can abuse your binkley with my frontdoor if
you want :) :P

I don't know how to get BT to dial out yet on telnet, but I'll work
on it.

that depends on your "shim"... in my case, with Warp 3 Connect, i use Ray Gwinn's SIO package and "dialing" an IP number is no different than dialing a POTS number as far as FD is concerned... the only "problem" that need be contended with is special characters in the dialing string... ie: dots instead of dashes and similar...

)\/(ark


* Origin: (1:3634/12)

Hi, Mark-

Quoting mark lewis from a message to Sean Dennis <=-

can i/we assume that this is on the standard telnet port or do we
need to do something special and specify an alternative port??

Standard port. From what it looks like from running overnight, things look like they're working as far as the system answering the phone. :)

that depends on your "shim"... in my case, with Warp 3 Connect, i use
Ray Gwinn's SIO package and "dialing" an IP number is no different
than dialing a POTS number as far as FD is concerned... the only
"problem" that need be contended with is special characters in the
dialing string... ie: dots instead of dashes and similar...

The dialing string problem is what I'm concerned about. Like you, I run SIO 1.60d, so I know I can get out with no problems.

What I'm wondering is if BT might get confused when I want to send mail via POTS and what not. When I get the POTS set up going, if there's problems, I'll
probably pull BT off the telnet node.

Later,
Sean

// sean@nsbbs.info | http://nsbbs.info | ICQ: 19965647

--- Telegard/2 v3.09.g2-sp4/mL
* Origin: Nocturnal State BBS - bbs.nsbbs.info (1:18/200)

Hello Sean!

08 Oct 09 19:36, you wrote to All:

I've set up BinkleyTerm to answer the first (and currently only)
telnet node on my BBS. So if any of you that have BT set up for
telnet, give it a try by crashing me a netmail or something. :) I
don't know how to get BT to dial out yet on telnet, but I'll work on
it.

Try binkp for internet polls as I don't think BT does so.

Vince

--- Linux/Mbse/GoldED+/LNX 1.1.5
* Origin: Air Applewood, The Linux Gateway to the UK (2:250/1)

Hello, Vince.

Friday October 09 2009 at 18:10, you wrote to me:

Try binkp for internet polls as I don't think BT does so.

I've been using BinkP for about 10 years now (via Internet Rex)...so if BT won't do it right, I'll just take it off the telnet node. BT would serve me better as the dialup FEM.

Later,
Sean

//sean@nsbbs.info | http://nsbbs.info | ICQ: 19965647

... Behind every argument is someone's ignorance.
--- GoldED/2 3.0.1
* Origin: Nocturnal State BBS - Johnson City, TN - bbs.nsbbs.info (1:18/200)

Hello Sean.

09 Oct 09 08:31, you wrote to mark lewis:

What I'm wondering is if BT might get confused when I want to send
mail via POTS and what not. When I get the POTS set up going, if
there's problems, I'll probably pull BT off the telnet node.

It's nothing that can't be dealt with. I have Binkley on my telnet node also. It took a little fiddling with ModemTrans, etc. to make Binkley dial POTS calls on Node 1 only, Telnet calls on Node 2 only, and not dial BinkP capable nodes at all. If your interested, I can send you my Binkley.CFG, FastLst.CFG, etc.

Later,

Andrew

--- GoldED+/LNX 1.1.5
* Origin: Phoenix BBS * phxbbs.dyndns.org (1:320/219)

can i/we assume that this is on the standard telnet port or do we
need to do something special and specify an alternative port??

Standard port. From what it looks like from running overnight,
things look like they're working as far as the system answering the
phone. :)

that's good! :)

that depends on your "shim"... in my case, with Warp 3 Connect, i use
Ray Gwinn's SIO package and "dialing" an IP number is no different
than dialing a POTS number as far as FD is concerned... the only
"problem" that need be contended with is special characters in the
dialing string... ie: dots instead of dashes and similar...

The dialing string problem is what I'm concerned about. Like you,
I run SIO 1.60d, so I know I can get out with no problems.

well, the only other thing is if the init string faciliates "normal" answering... a standard init string and SIO on telnet or POTS should easily answer either with no problems at all if the POTS side is direct to the modem and then to BT...

)\/(ark

What I'm wondering is if BT might get confused when I want to send
mail via POTS and what not. When I get the POTS set up going, if
there's problems, I'll probably pull BT off the telnet node.

Later,
Sean

// sean@nsbbs.info | http://nsbbs.info | ICQ: 19965647

___ Telegard/2 v3.09.g2-sp4/mL
- Origin: Nocturnal State BBS - bbs.nsbbs.info (1:18/200)

* Origin: (1:3634/12)

that depends on your "shim"... in my case, with Warp 3 Connect, i use
Ray Gwinn's SIO package and "dialing" an IP number is no different
than dialing a POTS number as far as FD is concerned... the only
"problem" that need be contended with is special characters in the
dialing string... ie: dots instead of dashes and similar...

The dialing string problem is what I'm concerned about. Like you,
I run SIO 1.60d, so I know I can get out with no problems.

right... i figured that was what you were using...

What I'm wondering is if BT might get confused when I want to send
mail via POTS and what not. When I get the POTS set up going, if
there's problems, I'll probably pull BT off the telnet node.

ahhh... hummm... i don't know your setup or how binkley does in a multi-node setup... on my frontdoor setup, i have one master config for the pots nodes and
then each of the telnet nodes has its own specific config... FD's routing tables are done the same way... one master for the pots nodes and then specific
ones for each telnet node... remember, frontdoor is a dynamic routing mailer so
it builds its packets and outbound files on the fly when it scans the netmail area for outbound traffic...

i've also had to set specific settings for those nodes that i FTN over telnet with... i think this was done in the modem manager area based on the node's nodelist flags... i know that if i forget this, stuff still wants to go via pots instead of telnet or it just sits and waits if i forgot the routing stuffs... anyway, once i set a system for telnet, the pots side ignores it and always puts it on hold... if i need to force it to go via pots, then i manually
use one of the pots nodes and force it to go now...

once i got it all set up and working, it works a treat... it is the steps needing to be done for the nodes that i don't always recall... oh yeah, i also use environment variables for each of the mailer nodes' numbers for those remote systems... fd's nodelist compiler then set the nodelist so that each mail looks to its local environment for the number for a node... in this way, i
have to manually check the nodelist (since the way it was going to be done was never fully implemented and then others had to go down another road and muck other stuff up) and ensure that i have the proper IP or domain name for a node and if they also have pots, that i have the right pots number on the pots nodes
side...

again, i don't know how binkleyterm goes together for a multinode setup or if you can have it look to different configs for some nodes... i definitely don't know that it does environment variables for nodelist phone numbers and the like
nor do i have a clue as to how the routing stuff would work because that would mean that your mail tosser or another tool would need to handle things that my FD handles internally...

i hope it makes some sense and that you can glean necessary information from the above... if you have more questions, just ask ;)

)\/(ark


* Origin: (1:3634/12)

I've set up BinkleyTerm to answer the first (and currently only)
telnet node on my BBS. So if any of you that have BT set up for
telnet, give it a try by crashing me a netmail or something. :) I
don't know how to get BT to dial out yet on telnet, but I'll work on
it.

Try binkp for internet polls as I don't think BT does so.

binkp is NOT FTN over telnet... binkp is something completely different ;)

)\/(ark


* Origin: (1:3634/12)

HI Mark, and SEan,

On Tue 2037-Oct-13 17:34, mark lewis (1:3634/12) wrote to Sean Dennis:

What I'm wondering is if BT might get confused when I want to send
mail via POTS and what not. When I get the POTS set up going, if
there's problems, I'll probably pull BT off the telnet node.

ahhh... hummm... i don't know your setup or how binkley does in a multi-node setup... on my frontdoor setup, i have one master config
for the pots nodes and then each of the telnet nodes has its own
specific config... FD's routing tables are done the same way... one
master for the pots nodes and then specific ones for each telnet
node... remember, frontdoor is a dynamic routing mailer so it builds
its packets and outbound files on the fly when it scans the netmail
area for outbound traffic...

Much the same with binkley, the task number config parameter is important here I"m sure. ONly worked with one multinode
setup and that was many moons ago. But, iirc. that's what
we did was a config for each node. NOw mind you all three
were pots.


AS for routing, squish or his mail processor would handle
that as Bink is a static mailer. SAme inbound/outbound dirs though pointed to by all versions.

Back in the day there was lots of help in this echo for
getting multinode setups humming along nicely, especially
with os2, so anybody who's got this echo archived way back
could probably be quite a resource if you still have
trouble.


Regards,
Richard
--- timEd 1.10.y2k+
* Origin: Radio REscue net operations BBS (1:116/901)

Replying to a message of Sean Dennis to All:

Hello, All.

I've set up BinkleyTerm to answer the first (and currently only)
telnet node on my BBS. So if any of you that have BT set up for
telnet, give it a try by crashing me a netmail or something. :) I
don't know how to get BT to dial out yet on telnet, but I'll work on
it.

If you were using Ray Gwinn's Virtual Modem you wouldn't have that problem. <g> It works just fine with Binkley, I used it a couple of times several years ago to contact Dale Ross' system, then I switched to Internet Rex and a BinkD connection.

--- FleetStreet 1.19+
* Origin: Bob's Boneyard, Emerson, Iowa (1:300/3)

Hello, Bob.

Tuesday October 13 2009 at 06:30, you wrote to me:

If you were using Ray Gwinn's Virtual Modem you wouldn't have that problem. <g> It works just fine with Binkley, I used it a couple of
times several years ago to contact Dale Ross' system, then I switched
to Internet Rex and a BinkD connection.

I've been running SIO v1.60d since around 1998 now. :)

Later,
Sean

//sean@nsbbs.info | http://nsbbs.info | ICQ: 19965647

... An armed man is a citizen. An unarmed man is a subject.
--- GoldED/2 3.0.1
* Origin: Nocturnal State BBS - Johnson City, TN - bbs.nsbbs.info (1:18/200)

Much the same with binkley, the task number config parameter is
important here I"m sure. ONly worked with one multinode
setup and that was many moons ago. But, iirc. that's what
we did was a config for each node. NOw mind you all three
were pots.

shouldn't really matter as long as each node can be config'd specially for the needs of that node...

AS for routing, squish or his mail processor would handle
that as Bink is a static mailer. SAme inbound/outbound dirs though pointed to by all versions.

hummm... therein lays the problem... can tossers handle multiple routings for static mail bundles?? FD can because it is dynamic in building its outbound stuffs but if a BSO style tosser cannot build multiple ?lo files indicating different "status'" for the same static outbound bundles for separate nodes, this may be a problem...

Back in the day there was lots of help in this echo for
getting multinode setups humming along nicely, especially
with os2, so anybody who's got this echo archived way back
could probably be quite a resource if you still have
trouble.

agreed... sadly, though, my archiving is more like a "live feed" in that my set
up simply retains postings for a much longer time than others... currently that's only one year :?

)\/(ark


* Origin: (1:3634/12)

HI Mark,

On Wed 2037-Oct-14 19:08, mark lewis (1:3634/12) wrote to Richard Webb:

Much the same with binkley, the task number config parameter is
important here I"m sure. ONly worked with one multinode
setup and that was many moons ago. But, iirc. that's what
we did was a config for each node. NOw mind you all three
were pots.

shouldn't really matter as long as each node can be config'd
specially for the needs of that node...

THat's as I thought as well, as long as the particulars for
that connection scheme are set up properly in that node's
config you're golden.

AS for routing, squish or his mail processor would handle
that as Bink is a static mailer. SAme inbound/outbound dirs though pointed to by all versions.

hummm... therein lays the problem... can tossers handle multiple
routings for static mail bundles?? FD can because it is dynamic in
building its outbound stuffs but if a BSO style tosser cannot build multiple ?lo files indicating different "status'" for the same
static outbound bundles for separate nodes, this may be a problem...

DOn't think it can do that. DOnt' know how folks handle
situations where they connect with somebody who's got ip and pots both.

IMportant thing with multinode binkleys and your tosser,
i.e. squish in my case, would be to properly configure the
flags directory, and make sure everything put its busy flags in the appropriate
place.

Back in the day there was lots of help in this echo for
getting multinode setups humming along nicely, especially
with os2, so anybody who's got this echo archived way back
could probably be quite a resource if you still have
trouble.

agreed... sadly, though, my archiving is more like a "live feed" in
that my set up simply retains postings for a much longer time than others... currently that's only one year :?

YEp, wonderd how long you archived. I do it by number of
messages in most echoes, just out of habit from the old
days, but some are by days.

Bob Juge would have been your guy for that as he was doing
it. Also the other MR. LEwis might be of some assistance to SEan in this regard. THink he's running bt.

Regards,
Richard
--- timEd 1.10.y2k+
* Origin: Radio REscue net operations BBS (1:116/901)

HI Mark,

following up a message from Richard Webb to mark lewis:

AS for routing, squish or his mail processor would handle
that as Bink is a static mailer. SAme inbound/outbound dirs though pointed to by all versions.

hummm... therein lays the problem... can tossers handle multiple
routings for static mail bundles?? FD can because it is dynamic in
building its outbound stuffs but if a BSO style tosser cannot build multiple ?lo files indicating different "status'" for the same
static outbound bundles for separate nodes, this may be a problem...

Also tough because most multinode setups I've seen they
shared inbound and outbound directories. I.e. tosser builds one lot file, or the pkt if a raw pkt with the .out/cut/hut
extension, changed to pkt on the fly.

BUt then how do you keep different versions of fd from
clashing over who's manipulating the netmail area in this
situationn?

Another thing i just remembered which SEan may already
remember is that when running his telnet binkley that task
might want to use the noemsi config verb because iirc one
can't do zmodem and its variants over a telnet connection,
hence no zedzap.


Regards,
Richard
--- timEd 1.10.y2k+
* Origin: Radio REscue net operations BBS (1:116/901)

Hello mark!

13 Oct 09 17:47, you wrote to me:

Try binkp for internet polls as I don't think BT does so.

binkp is NOT FTN over telnet... binkp is something completely
different ;)

Point made, must have been half asleep.



Vince

--- Linux/Mbse/GoldED+/LNX 1.1.5
* Origin: Air Applewood, The Linux Gateway to the UK (2:250/1)

Hello, Richard.

Thursday October 15 2009 at 04:19, you wrote to mark lewis:

Another thing i just remembered which SEan may already
remember is that when running his telnet binkley that task
might want to use the noemsi config verb because iirc one
can't do zmodem and its variants over a telnet connection,
hence no zedzap.

I use ZModem all the time over telnet on my BBS-not sure if you know that. :)

In fact, I can sometimes squeeze 60K/s speeds out of ZModem over telnet.

Later,
Sean

//sean@nsbbs.info | http://nsbbs.info | ICQ: 19965647

... Idleness is the holiday of fools.
--- GoldED/2 3.0.1
* Origin: Nocturnal State BBS - Johnson City, TN - bbs.nsbbs.info (1:18/200)

Hi Sean,

Another thing i just remembered which SEan may already
remember is that when running his telnet binkley that task
might want to use the noemsi config verb because iirc one
can't do zmodem and its variants over a telnet connection,
hence no zedzap.

I use ZModem all the time over telnet on my BBS-not sure if you know that. :)

In fact, I can sometimes squeeze 60K/s speeds out of ZModem over telnet.

You probably have this file on your system somewhere:

binkmaxp.zip

Over here, it's in the maxfdn/maxutil file directory.. It's an outline of how to install Binkley/MaxP multinode... I remember using that file way back when I
was running Maximus <g>. The file would obviously help when setting up any bbs
with Binkley and OS/2.. least I think it would <g>

Take care,
Janis

--- BBBS/LiI v4.01 Flag
* Origin: Prism bbs (1:261/38)

HI SEan,

On Thu 2037-Oct-15 10:59, Sean Dennis (1:18/200) wrote to Richard Webb:

Another thing i just remembered which SEan may already
remember is that when running his telnet binkley that task
might want to use the noemsi config verb because iirc one
can't do zmodem and its variants over a telnet connection,
hence no zedzap.

I use ZModem all the time over telnet on my BBS-not sure if you know
that. :)

In fact, I can sometimes squeeze 60K/s speeds out of ZModem over
telnet.

Another fidonet urban legend debunked!!! THat was one I"d
read a couple of places in old fidonet docs from the early
days of fidonet transport over the internet that I took as
gospel, as the writers were known to me in my old fido days
to be those that put out the straight dope. sO much for
that <g>.

Regards,
Richard
--- timEd 1.10.y2k+
* Origin: Radio REscue net operations BBS (1:116/901)

Much the same with binkley, the task number config parameter is
important here I"m sure. ONly worked with one multinode
setup and that was many moons ago. But, iirc. that's what
we did was a config for each node. NOw mind you all three
were pots.

shouldn't really matter as long as each node can be config'd
specially for the needs of that node...

THat's as I thought as well, as long as the particulars for
that connection scheme are set up properly in that node's
config you're golden.

should be...

AS for routing, squish or his mail processor would handle
that as Bink is a static mailer. SAme inbound/outbound dirs though pointed to by all versions.

hummm... therein lays the problem... can tossers handle multiple
routings for static mail bundles?? FD can because it is dynamic in
building its outbound stuffs but if a BSO style tosser cannot build multiple ?lo files indicating different "status'" for the same
static outbound bundles for separate nodes, this may be a problem...

DOn't think it can do that. DOnt' know how folks handle
situations where they connect with somebody who's got ip and pots
both.

yeah... that's what part of my setup is all about... if i have someone set up for FTN over telnet (not binkd stuffs), then the pots nodes all place that traffic on hold when they build their outbound packages... the telnet nodes all
set it as normal or crash or whatever their current schedule calls for...

i guess FD's dynamic stuff is similar to having it build its own ?lo files but those ?lo files are also specific to the node as well as to the destination system... FD uses the file extension to denote the node number the file is for and the content of the file denotes the addresses and "flavor"...

IMportant thing with multinode binkleys and your tosser,
i.e. squish in my case, would be to properly configure the
flags directory, and make sure everything put its busy flags in the appropriate place.

semaphores are extremely important in any multinode environment and also those that utilize background processed performing tasks... consider if your setup spawns a new shell to toss mail while the mailer continues to run... you don't want a downlink connecting and missing new mail that is being tossing into the bundle...

Back in the day there was lots of help in this echo for
getting multinode setups humming along nicely, especially
with os2, so anybody who's got this echo archived way back
could probably be quite a resource if you still have
trouble.

agreed... sadly, though, my archiving is more like a "live feed" in
that my set up simply retains postings for a much longer time than others... currently that's only one year :?

YEp, wonderd how long you archived. I do it by number of
messages in most echoes, just out of habit from the old
days, but some are by days.

a few years back i went to 365 days... but i have some that are set for nothing
and they carry several thousand messages in them... most of those are my beta areas, though...

Bob Juge would have been your guy for that as he was doing
it. Also the other MR. LEwis might be of some assistance to SEan
in this regard. THink he's running bt.

yup and yup on both accounts...

)\/(ark


* Origin: (1:3634/12)

AS for routing, squish or his mail processor would handle
that as Bink is a static mailer. SAme inbound/outbound dirs though pointed to by all versions.

hummm... therein lays the problem... can tossers handle multiple
routings for static mail bundles?? FD can because it is dynamic in
building its outbound stuffs but if a BSO style tosser cannot build multiple ?lo files indicating different "status'" for the same
static outbound bundles for separate nodes, this may be a problem...

Also tough because most multinode setups I've seen they
shared inbound and outbound directories. I.e. tosser builds one
lot file, or the pkt if a raw pkt with the .out/cut/hut
extension, changed to pkt on the fly.

yes... this is a problem for BSO style but not for dynamic setups...

BUt then how do you keep different versions of fd from
clashing over who's manipulating the netmail area in this
situationn?

each one scans the netmail directory (remember, FD uses file attach to attach the bundles to the destination and builds PKTs on its own for "raw" netmail messages that are not packed into bundles by the tosser) and builds its own outbound control file (akin to BSO ?lo files)... when a node sends or receives traffic, it creates a semaphore that tells all the other nodes to recheck and rescan the netmail directory to see what is new or is no longer available and they rebuild if neccessary otherwise their control file remains the same... each node builds its control file based on its routing... since there can be one "main" routing file and separate ones for certain nodes, there's no clash or problem...

i will say that it is possible that more than one node may attempt to connect to deliver traffic to a destination but that should not be a problem as either or both ends should recognize the fact that they another live connection and drop all but one of them...

Another thing i just remembered which SEan may already
remember is that when running his telnet binkley that task
might want to use the noemsi config verb because iirc one
can't do zmodem and its variants over a telnet connection,
hence no zedzap.

i do EMSI with zmodem transfers over here all the time... the problem with using the older FTN transfer protocols over telnet is the timing... the older protocols (xmodem, ymodem, zmodem and all their variants that FTN uses) expect to be used on a dedicated circuit that is pretty speedy... as such, they expect
ACKs within certain timeframes... a shared circuit like an internet pipe might be carrying so much traffic that the timers timeout before the ACKs arrive... with this in mind, the faster the pipe, the better... on a 56k POTS dialup internet connection with nothing else going thru the pipe at all, you can probably use zmodem and variants without too much trouble but the others will have problems... zmodem differs from the others in that it doesn't expect any ACKs for good packets transferred but bad ones will garner a NAK to the sender so it will back up and resend it...

)\/(ark


* Origin: (1:3634/12)

Try binkp for internet polls as I don't think BT does so.

binkp is NOT FTN over telnet... binkp is something completely
different ;)

Point made, must have been half asleep.

no problem :)

)\/(ark


* Origin: (1:3634/12)

Hello Richard!

15 Oct 09 00:41, Richard Webb wrote to mark lewis:

DOn't think it can do that. DOnt' know how folks handle
situations where they connect with somebody who's got ip and pots
both.

Lots of ways to do it depending on how much divergence you can handle between node setups and how sophisticated your partitioning requirements are.
Simpler kludges are:

Assign high costs to the addresses/phone#'s of concern and use separate .EVT files that only grant the intended node permission to call when cost greater than xxx.

For the common case of IP=yes/analog=no, you can just use the DIAL verb to translate the destination nodelist phone # into your own...which will always be
busy if the analog node tries to dial it.<g> The IP node will already have to have some custom nodelist compilation/DIAL substitution to convince BT to call an IP address or hostname instead of the listed POTS number. I use this trick for my own IP-only crash downlinks because BT will try to crash a call to the parent listing of the Pvt/Unpublished listing...which in this case, is me.<g>

Since my RC, my uplink and myself have dual-purpose listings, I let my analog and IP mailers all have at it...so I have failover if one channel is having trouble. I just have the IP node rescan every minute and the analog node rescan every 10 minutes. Once in a blue moon, something gets scanned out at minute 9.5 and the analog node actually beats the IP node to it and sticks me with a one minute toll call.<g>

.\\ike

--- GoldED/2 2.50+
* Origin: -=( The TechnoDrome )=- Austin,TX 512-327-8598 33.6k (1:382/61)

Hello, mark.

Thursday October 15 2009 at 15:03, you wrote to Richard Webb:

i do EMSI with zmodem transfers over here all the time... the problem
with using the older FTN transfer protocols over telnet is the
timing... the older protocols (xmodem, ymodem, zmodem and all their

It's also the protocol driver. I use P for OS/2, a real 32-bit driver that's better than anything else I've ever used, save for PD-ZModem for DOS. Absolutely painless to use and really fast to boot; it was written by someone who knew OS/2 really well. PD-ZModem was written by someone who knew how to optimize their DOS stuff to the T. Used PDZ with ProBoard under DOS (OS/2-DOS)
and it was amazingly fast, almost as fast as P!

But I digress. :)

Later,
Sean

//sean@nsbbs.info | http://nsbbs.info | ICQ: 19965647

... Some rise by sin and some by virtue fall.
--- GoldED/2 3.0.1
* Origin: Nocturnal State BBS - Johnson City, TN - bbs.nsbbs.info (1:18/200)

HI Mark,

On Thu 2037-Oct-15 14:54, mark lewis (1:3634/12) wrote to Richard Webb:

<snippage>

shouldn't really matter as long as each node can be config'd
specially for the needs of that node...

Agreed, and there's ways to accomplish about anything <g>.

<snip again>

AS for routing, squish or his mail processor would handle
that as Bink is a static mailer. SAme inbound/outbound dirs though pointed to by all versions.

hummm... therein lays the problem... can tossers handle multiple
routings for static mail bundles?? FD can because it is dynamic in
building its outbound stuffs but if a BSO style tosser cannot build multiple ?lo files indicating different "status'" for the same
static outbound bundles for separate nodes, this may be a problem...

not an option. Instead, what you do is process the
nodelist. EXample, you've got a node you regularly connect
with and crash packets to. This node has both pots and your other common scheme. YOu don't want to dial pots to send
those crash bundles. so, you replace that node's pots phone no with unpublished using your favorite nodelist compiler.
Need to change your mind and dial him pots? Grab the right
phone number from the raw nodelist as distributed, recompile nodelist, you're happening. Other scheme comes back live,
switcharoo your nodelist compiler control file back,
recompile.

Most nodelist compilers that create a nodelist binkley can
use will let you do the above quite handily iirc.

i guess FD's dynamic stuff is similar to having it build its own ?lo
files but those ?lo files are also specific to the node as well as
to the destination system... FD uses the file extension to denote
the node number the file is for and the content of the file denotes
the addresses and "flavor"...

YEp, similar. YOur tosser and other utilities build the
*.*lo files. There will be a file in my outbound when I
write this message created/updated by squish with a file
name of 0e32000c.clo detailing paths and filenames to be
sent to you.

so, if you and I had multiple connection schemes between us
such as telnet and pots and I were running multinode I'd
possibly want to prefer the telnet connection. But, in my
case maybe I"d prefer the pots, only use the telnet if there were trouble on lines between us. IF I want to prefer the
telnet I change your pots entry to unpublished so that bt
pots doesn't try to dial you.

But, if I want to prefer the pots as primary I"ll want to
change your nodelist flags entry, again doable with my
nodelist compiler to not show the telnet capability. Or, I
can leave the nodelist alone, and the mode that gets there
first transacts a session with yours. Meanwhile, if
assuming I"m running other processes since I"m running
multinode those other processes are aware of which one's
talking with you and won't touch mail bundles to/from your
system.

<snip again>

Bob Juge would have been your guy for that as he was doing
it. Also the other MR. LEwis might be of some assistance to SEan
in this regard. THink he's running bt.

yup and yup on both accounts...

When I helped a friend get it all going I referred to things I"d seen in this echo quite a bit, but that was way back in
the day <g>.


Regards,
Richard
--- timEd 1.10.y2k+
* Origin: Radio REscue net operations BBS (1:116/901)

<snip again>
AS for routing, squish or his mail processor would handle
that as Bink is a static mailer. SAme inbound/outbound dirs though pointed to by all versions.

hummm... therein lays the problem... can tossers handle multiple
routings for static mail bundles?? FD can because it is dynamic in
building its outbound stuffs but if a BSO style tosser cannot build multiple ?lo files indicating different "status'" for the same
static outbound bundles for separate nodes, this may be a problem...

not an option. Instead, what you do is process the
nodelist. EXample, you've got a node you regularly connect
with and crash packets to. This node has both pots and your other
common scheme. YOu don't want to dial pots to send
those crash bundles. so, you replace that node's pots phone no
with unpublished using your favorite nodelist compiler.
Need to change your mind and dial him pots? Grab the right
phone number from the raw nodelist as distributed, recompile
nodelist, you're happening. Other scheme comes back live,
switcharoo your nodelist compiler control file back,
recompile.

ugh... i really do like FD's nodelist compiling stuff... all FD does is generate b-tree indexes on the nodelist and then if there are overrides for any
nodes, those go into the b-tree index so they are used instead of the default nodelist data... with FD being able to use environment variables for nodelist entries, one simply replaces the phone number with the environment variable and
then the mailer (FD) looks to the environment variable for the number to use...
since each node maintains its own environment settings, one node can have

set foo=1-800-555-0100

and another node can have

set foo=some.domain.whatever

where "foo" is the EV (environment variable) assigned for the override for a node's phone number...

if i have stuff for a node that has both POTS and FTN over telnet, and i want to "crash" (i use immediate instead of crash) what i have waiting for them via POTS, i simply go to one of the POTS nodes, look at that mailer's outboud queue
and change the flavor of that destination system's bundle(s) from hold to "normal", "crash" or "immediate"... all the other nodes still retain their settings for that destination... the one mailer node then does the connection and signals the others when it is successful so they will rescan and rebuild their outbound control files... i don't have to shut down all the mailers, take
the few minutes to recompile the nodelist and restart all the mailers...

Most nodelist compilers that create a nodelist binkley can
use will let you do the above quite handily iirc.

i'm sure ;)

i guess FD's dynamic stuff is similar to having it build its own ?lo
files but those ?lo files are also specific to the node as well as
to the destination system... FD uses the file extension to denote
the node number the file is for and the content of the file denotes
the addresses and "flavor"...

YEp, similar. YOur tosser and other utilities build the
*.*lo files. There will be a file in my outbound when I
write this message created/updated by squish with a file
name of 0e32000c.clo detailing paths and filenames to be
sent to you.

right... and there's the main difference... there's only one ?lo file for all the mailer nodes to see and use... it cannot be a hlo, flo and clo all at the same time so that individual mailer nodes can act on it the way they need to...

so, if you and I had multiple connection schemes between us
such as telnet and pots and I were running multinode I'd
possibly want to prefer the telnet connection. But, in my
case maybe I"d prefer the pots, only use the telnet if there were
trouble on lines between us. IF I want to prefer the
telnet I change your pots entry to unpublished so that bt
pots doesn't try to dial you.

right... that is one method... it can also be done like this with FD but it is much easier and simpler to simply set that mailer node's routing table to hold that mail during that scheduled event... so these mailer nodes see that mail as
"hold" and those see that exact same stuff as "normal" (or "immediate" or "crash" or whatever) and each can act on it separately...

But, if I want to prefer the pots as primary I"ll want to
change your nodelist flags entry, again doable with my
nodelist compiler to not show the telnet capability. Or, I
can leave the nodelist alone, and the mode that gets there
first transacts a session with yours. Meanwhile, if
assuming I"m running other processes since I"m running
multinode those other processes are aware of which one's
talking with you and won't touch mail bundles to/from your
system.

yup... i've had times where i've had more than one POTS node pick up the line and dial to the remote while at the same time, more than one of the internet nodes also went to connect to the same destination... in that case, it is the luck of the draw as to which one gets the first connection and makes the transfer ;)

<snip again>

Bob Juge would have been your guy for that as he was doing
it. Also the other MR. LEwis might be of some assistance to SEan
in this regard. THink he's running bt.

yup and yup on both accounts...

When I helped a friend get it all going I referred to things I"d
seen in this echo quite a bit, but that was way back in
the day <g>.

as was with many echos in fidonet, there was a huge amount of information on almost any subject that traveled between all of our systems... it really is sad
that folk have folked to the internet for eye-candy without the real meat of the meal...

)\/(ark


* Origin: (1:3634/12)

i do EMSI with zmodem transfers over here all the time... the problem
with using the older FTN transfer protocols over telnet is the
timing... the older protocols (xmodem, ymodem, zmodem and all their

It's also the protocol driver.

right... the protocol driver (the actual protocol executable) is where the coder would have to tighten or loosen the timing windows so the protocols would
work over slower connection tunnels...

I use P for OS/2, a real 32-bit driver that's better than anything
else I've ever used, save for PD-ZModem for DOS. Absolutely
painless to use and really fast to boot; it was written by someone
who knew OS/2 really well. PD-ZModem was written by someone who
knew how to optimize their DOS stuff to the T. Used PDZ with
ProBoard under DOS (OS/2-DOS) and it was amazingly fast, almost as
fast as P!

But I digress. :)

i know the feeling... when joho had to rewrite FD and did it with an eye specifically aimed at using the internet for the connection, he had to tweak several of the protocols for looser timing windows to allow those ACKs and such
plenty of time to return thru the congested pipeline... since he had the 3rd party sources for the protocols (more expensive library licensing) he was using, this was a pretty trivial matter... the real problem comes with software
that uses 3rd party libraries that are only available in compiled unit or obj format (free or low cost licensing)... without the sources or some way to adjust the timings via parameters in the routine's call vectors, these are frought with peril... a very congested pipeline and even tcp/ip packets arriving out of order can easily cause a protocol to stop and backup or even miss ACKs and NAKs...

)\/(ark


* Origin: (1:3634/12)

HI MIke,

On Thu 2037-Oct-15 14:28, Mike Tripp (1:382/61) wrote to Richard Webb:

Lots of ways to do it depending on how much divergence you can
handle between node setups and how sophisticated your partitioning requirements are. Simpler kludges are:

Assign high costs to the addresses/phone#'s of concern and use
separate .EVT files that only grant the intended node permission to
call when cost greater than xxx.

YEp, that's a good method.

YOu and I both mentioned the nodelist substitution method,
crossed in echo traffic <g>.

Since my RC, my uplink and myself have dual-purpose listings, I let
my analog and IP mailers all have at it...so I have failover if one
channel is having trouble. I just have the IP node rescan every
minute and the analog node rescan every 10 minutes. Once in a blue
moon, something gets scanned out at minute 9.5 and the analog node
actually beats the IP node to it and sticks me with a one minute
toll call.<g>

CAn see how that would work too. OEN multinode setup I
assisted quite a bit with had one node didn't answer the
phone, and only did dial out during the wee small hours of
the morning, or during the day to exchange mail with me
since I was his feeding hub.

Regards,
Richard
--- timEd 1.10.y2k+
* Origin: Radio REscue net operations BBS (1:116/901)

Hi Mark,

On Thu 2037-Oct-15 18:48, mark lewis (1:3634/12) wrote to Richard Webb:

that as Bink is a static mailer. SAme inbound/outbound dirs though pointed to by all versions.

hummm... therein lays the problem... can tossers handle multiple
routings for static mail bundles?? FD can because it is dynamic in
building its outbound stuffs but if a BSO style tosser cannot build multiple ?lo files indicating different "status'" for the same
static outbound bundles for separate nodes, this may be a problem...

not an option. Instead, what you do is process the
nodelist. EXample, you've got a node you regularly connect
with and crash packets to. This node has both pots and your other
common scheme. YOu don't want to dial pots to send
those crash bundles. so, you replace that node's pots phone no
with unpublished using your favorite nodelist compiler.

<snip>

ugh... i really do like FD's nodelist compiling stuff... all FD does
is generate b-tree indexes on the nodelist and then if there are
overrides for any nodes, those go into the b-tree index so they are
used instead of the default nodelist data... with FD being able to
use environment variables for nodelist entries, one simply replaces
the phone number with the environment variable and then the mailer
(FD) looks to the environment variable for the number to use...

YOu're not using the raw nodelist with bt, at least with
version 7. IT creates its indexes it needs.

Substitution of number to dial or node's flags is easy, at
least in xlaxnode or tbbsnc. Just put it in the control
file. WAnt to use the flags or dial number from the raw
nodelist as is, just comment that line out of your control
file, and recompile.

When I was feeding Daryl Stout for awhile last summer before he got everything squared away I was substituting and
stuffing his pots number into my nodelist.

if i have stuff for a node that has both POTS and FTN over telnet,
and i want to "crash" (i use immediate instead of crash) what i have waiting for them via POTS, i simply go to one of the POTS nodes,
look at that mailer's outboud queue and change the flavor of that destination system's bundle(s) from hold to "normal", "crash" or "immediate"... all the other nodes still retain their settings for
that destination... the one mailer node then does the connection and signals the others when it is successful so they will rescan and
rebuild their outbound control files... i don't have to shut down
all the mailers, take the few minutes to recompile the nodelist and
restart all the mailers...

YEp, can see that. I don't think squish uses flavors such
as immediate and direct the way dynamic mailers do however.
OF course, with bink you've got one set of outbounds as
well between all nodes. so, the only thing other binkleys
need to be aware of is that you're connected on a certain
node.
Everybody still communicates between themselves with busy
flags in the appropriate directory <g>.

TWo ways of going about the same thing.

Most nodelist compilers that create a nodelist binkley can
use will let you do the above quite handily iirc.

i'm sure ;)

YEp, quite easy. AS I noted xlaxnode's fairly easy, and I"m sure fastlst and qnode were as well. I think some still use fastlst, but I haven't heard anybody mention qnode in years
<g>.

<snip>

YEp, similar. YOur tosser and other utilities build the
*.*lo files. There will be a file in my outbound when I
write this message created/updated by squish with a file
name of 0e32000c.clo detailing paths and filenames to be
sent to you.

right... and there's the main difference... there's only one ?lo
file for all the mailer nodes to see and use... it cannot be a hlo,
flo and clo all at the same time so that individual mailer nodes can
act on it the way they need to...

NOpe, that's why you manipulate the information available to those nodes such as MIke Tripp and I both described. hE
detailed another method using the cost field.

so, if you and I had multiple connection schemes between us
such as telnet and pots and I were running multinode I'd
possibly want to prefer the telnet connection. But, in my
case maybe I"d prefer the pots, only use the telnet if there were
trouble on lines between us. IF I want to prefer the
telnet I change your pots entry to unpublished so that bt
pots doesn't try to dial you.

right... that is one method... it can also be done like this with FD
but it is much easier and simpler to simply set that mailer node's
routing table to hold that mail during that scheduled event... so
these mailer nodes see that mail as "hold" and those see that exact
same stuff as "normal" (or "immediate" or "crash" or whatever) and
each can act on it separately...

YEp, horses for courses.
<snip again>

When I helped a friend get it all going I referred to

things I'd

seen in this echo quite a bit, but that was way back in
the day <g>.

as was with many echos in fidonet, there was a huge amount of
information on almost any subject that traveled between all of our systems... it really is sad that folk have folked to the internet
for eye-candy without the real meat of the meal...

INdeed it is. I really enjoyed turning newbies onto it as
well. iT was fun to see the light come on when they figured out how just plain
useful it could be.

Regards,
Richard
--- timEd 1.10.y2k+
* Origin: Radio REscue net operations BBS (1:116/901)

ugh... i really do like FD's nodelist compiling stuff... all FD does
is generate b-tree indexes on the nodelist and then if there are
overrides for any nodes, those go into the b-tree index so they are
used instead of the default nodelist data... with FD being able to
use environment variables for nodelist entries, one simply replaces
the phone number with the environment variable and then the mailer
(FD) looks to the environment variable for the number to use...

YOu're not using the raw nodelist with bt, at least with
version 7. IT creates its indexes it needs.

right but the question is if the raw nodelist is still required to be in place after the indexes are created or will the mailer operate with only the indexes??

Substitution of number to dial or node's flags is easy, at
least in xlaxnode or tbbsnc. Just put it in the control
file. WAnt to use the flags or dial number from the raw
nodelist as is, just comment that line out of your control
file, and recompile.

right... nothing different there...

When I was feeding Daryl Stout for awhile last summer before he got everything squared away I was substituting and
stuffing his pots number into my nodelist.

:)

if i have stuff for a node that has both POTS and FTN over telnet,
and i want to "crash" (i use immediate instead of crash) what i have waiting for them via POTS, i simply go to one of the POTS nodes,
look at that mailer's outboud queue and change the flavor of that destination system's bundle(s) from hold to "normal", "crash" or "immediate"... all the other nodes still retain their settings for
that destination... the one mailer node then does the connection and signals the others when it is successful so they will rescan and
rebuild their outbound control files... i don't have to shut down
all the mailers, take the few minutes to recompile the nodelist and
restart all the mailers...

YEp, can see that. I don't think squish uses flavors such
as immediate and direct the way dynamic mailers do however.
OF course, with bink you've got one set of outbounds as
well between all nodes. so, the only thing other binkleys
need to be aware of is that you're connected on a certain
node.

right... i was just being a bit more specific...

FWIW: for FD, it treats CRASH mail differently than IMMEDIATE mail... CRASH means go as soon as possible (and may include "directly to the destination site") whereas IMMEDIATE means "go right now, no matter what the schedule is set for... the DIRECT bit /can/ also come into play and it indicates that it should go directly to the destination whereas CRASH and IMMEDIATE may not...

Everybody still communicates between themselves with busy
flags in the appropriate directory <g>.

yup... things can be done a bit differently by using memory semaphore or conversation in an ICA (intra-communications area) but it is harder to work with, to a point, and is not as easy as simply creating a "flag" file on the disk... using an ICA or another memory type area doesn't use any disk space at all... that may be a good thing in some situations...

TWo ways of going about the same thing.

yup!

Most nodelist compilers that create a nodelist binkley can
use will let you do the above quite handily iirc.

i'm sure ;)

YEp, quite easy. AS I noted xlaxnode's fairly easy, and I"m sure
fastlst and qnode were as well. I think some still use fastlst,
but I haven't heard anybody mention qnode in years
<g>.

yeah, i dunno anymore...

<snip>
YEp, similar. YOur tosser and other utilities build the
*.*lo files. There will be a file in my outbound when I
write this message created/updated by squish with a file
name of 0e32000c.clo detailing paths and filenames to be
sent to you.

right... and there's the main difference... there's only one ?lo
file for all the mailer nodes to see and use... it cannot be a hlo,
flo and clo all at the same time so that individual mailer nodes can
act on it the way they need to...

NOpe, that's why you manipulate the information available to those
nodes such as MIke Tripp and I both described. hE
detailed another method using the cost field.

yes, that is another way but it is not optimal nor is it conducive to dynamic changes that may need to be made on the fly without having to goof around with the nodelist and its indexes...

<snip again>
When I helped a friend get it all going I referred to things I'd
seen in this echo quite a bit, but that was way back in the day
<g>.

as was with many echos in fidonet, there was a huge amount of
information on almost any subject that traveled between all of our systems... it really is sad that folk have folked to the internet
for eye-candy without the real meat of the meal...

INdeed it is. I really enjoyed turning newbies onto it as
well. iT was fun to see the light come on when they figured out
how just plain useful it could be.

in more ways than one, too! i remember a time when there were many businesses using fidonet style technology for their communications capabilities... many of
the traveling salesmen were set up as point systems and used a mailer to send and receive their orders and such... even a lot of tech support by those companies was done via FTN methods... much of this is now done via mailing lists or web based forum software... but none of that will ever touch all of the capabilities that the old methods offered...

)\/(ark


* Origin: (1:3634/12)

Hello Sean!

09 Oct 09 15:32, Sean Dennis wrote to Vince Coen:

I've been using BinkP for about 10 years now (via Internet Rex)...so
if BT won't do it right, I'll just take it off the telnet node. BT
would serve me better as the dialup FEM.

binkelayForce does binkp, fido, tfido, and modem calls, here i even have a gentoo ebuild for this one, and after i removed "only_from" in my xinetd default config it started to work


Regards Benny


... there can only be one way of life, and it works :)

--- Msged/LNX 6.2.0 (Linux/2.6.33-gentoo (i686))
* Origin: http://www.region23.dk/ http://www.fido.dk/ (2:237/53)