Subj : binkley multinode, was something new
To : Richard Webb
From : mark lewis
Date : Thu Oct 15 2009 03:03 pm
RW> AS for routing, squish or his mail processor would handle
RW> that as Bink is a static mailer. SAme inbound/outbound dirs though
RW> pointed to by all versions.
ml> hummm... therein lays the problem... can tossers handle multiple
ml> routings for static mail bundles?? FD can because it is dynamic in
ml> building its outbound stuffs but if a BSO style tosser cannot build
ml> multiple ?lo files indicating different "status'" for the same
ml> static outbound bundles for separate nodes, this may be a problem...
RW> Also tough because most multinode setups I've seen they
RW> shared inbound and outbound directories. I.e. tosser builds one
RW> lot file, or the pkt if a raw pkt with the .out/cut/hut
RW> extension, changed to pkt on the fly.
yes... this is a problem for BSO style but not for dynamic setups...
RW> BUt then how do you keep different versions of fd from
RW> clashing over who's manipulating the netmail area in this
RW> 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...
RW> Another thing i just remembered which SEan may already
RW> remember is that when running his telnet binkley that task
RW> might want to use the noemsi config verb because iirc one
RW> can't do zmodem and its variants over a telnet connection,
RW> 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...
