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... )\/(ark * Origin: (1:3634/12) .