= Сообщение: 1298 из 7128 ====================================== FTSC_PUBLIC = От : Michiel van der Vlist 2:280/5555 09 Oct 14 13:59:01 Кому : mark lewis 09 Oct 14 13:59:01 Тема : FTSC-5001 question FGHI : area://FTSC_PUBLIC?msgid=2:280/5555+5436844e На : area://FTSC_PUBLIC?msgid=1:3634/12.71+432eeb82 = Кодировка сообщения определена как: CP850 ================================== ============================================================================== Hello mark,
On Monday October 06 2014 15:46, you wrote to me:
MvdV>> If you mean binkd, no it is not. Perhaps you mean that it is MvdV>> enabled in the sample configuration file that comes with it. Do MvdV>> not use * in the host list of the node and defnode keywords and MvdV>> it will not use DNS distibuted nodelists.
ml> ummm... perhaps you should be logging your DNS traffic and looking at ml> what binkd is doing... that's how i found out about it some years back ml> ;)
I may do that some day, but it is not high on my list of priorities. Also, we are drifting from the topic at hand. Binkd's DNS is not a matter that concerns the FTSC, the binkd echo would be a suitable place to discuss it.
MvdV>>> The nodelist is the primary source of Fdionet connection MvdV>>> information. All the information to make a connection MUST be MvdV>>> present in the nodelist. DNS distributed nodelists as MvdV>>> documenetd in FTS-5004 are an /additional/ service, not a MvdV>>> replacement for the nodelist.
ml>> agreed on both accounts...
MvdV>> So a protocol flag without an associated host name or IP number MvdV>> in the nodelist is an error.
ml> i guess but you can't see that by the way a commonly used and ml> widespread mailer operates...
Binkd does not use the nodelist, so indeed you can not see it.
ml>> true... the way that line was laid out used the f.n.z because ml>> there's no IP or FQDN in the "system name" field so that flag was ml>> useless up to that point if the f.n.z was not performed...
MvdV>> That is not how it works....
ml> but that is how the software works...
Please enlighten me, what software works that way?
ml>> again, ISP connection limitations is the first thing that comes ml>> to mind...
MvdV>> How? The connection is either there or it isn't. If it is down, MvdV>> one can not use it at all, if it is up, why limit it to MvdV>> selected protocols?
ml> metering is the first thing that comes to mind...
Please explain to me how restricting on-line times depending on protocol helps to reduce problems causes by metered connections.
ml> we lost numerous african nodes due to metering of international ml> traffic...
You have made that claim before, but never backed it up. But if it is true, how would having different on-line times for different protocols have prevented it?
ml>> we tested a wireless ISP a while back and there were problems ml>> staying connected that were out of their hands...
MvdV>> Hmmm.. bad bussines..
ml> the business was good... it was the circumstances that were the ml> problem... that and some greedy child...
The client is without a connection. The reason is irrelevant, the customer will take his bussiness elsewhere.
But that is of no concern to the FTSC.
ml>> we have, at various times, had several feeds into this ml>> location... you speak above as if you are thinking about one ml>> system (multi-homed)
MvdV>> One system for Fidonet...
ml> over here, all internal FTN systems have one and only one RFC1918 ml> address... the multiple firewalls, one per connection, have one and ml> only one internal RFC1918 address with one and only one external WAN ml> address...
To nme that translates into "one system for Fidnet".
MvdV>> If a machine is reacheable via different path via different MvdV>> providers, than it is multi-homed. The sample nodelist line you MvdV>> presented suggested that was actually the case.
ml> the /machine/ is not multihomed... the internal *networks* are...
Nitpicking. From the outside one can not the layers between the machine and the WAN interfaces on the router(s). It is a machine reachable via different providers via different pathes. I.e mult-homed.
ml> but that doesn't fix the inherent blackhole of BSO :/ at least FD, IM ml> and other traditional mailers will tell you when mail is stuck and ml> undeliverable...
BSO is no more inherent black hole than AMA. You just need to look at it with different glasses. With AMA you need a mail reader to have a look at the outbound netmail folder, with BSO you need to look at the outbound director[y|ies].
With BSO it is actually simpeler, you do not even need a mail reader. "DIR *.?lo" on the outbound will do it...
And for those who want more: as Kees mentioned there are tools available.
ml> i have one, thank you... loosen up and look around, please... i point ml> back above to the comment about the african nodes we lost... they ml> could have moved to another zone as Z6 entities did but the metering ml> on their connection was causing them problems... the last african node ml> was robbed and that was the final nail in their coffin... but the ml> driving thing was the metering...
Abnd how would redefining the format of the nodelist have stopped that?
MvdV>> The smooth operation of the network is every sysop's concern... MvdV>>
ml> apparently not... not by the way some assume things are to be done and ml> how they attempt to force things on those around them... one need only ml> look at some of our members in the old soviet areas to see this... if ml> Z6 were still active,
If, if, bimblebiff....
ml> it could also be seen there... xxcarol related how the asian work ml> ethic demands that all workers under a manager had to quit if the ml> manager got fired... this carried over into their FTN operations, ml> too... when a NC was relieved everyone under him left too...
And what coild the FTSC have done to prevent that?
MvdV>>> Limited on-line times in addition of ZMH only makes sense for MvdV>>> POTS systems where a singes line is shared between Fidonet and MvdV>>> another service such as voice or fax.
ml>> respectfulyl, that is shortsighted and incorrect... see above ml>> about ISP connection limitations and metering...
You keep repeating that mantra, but still fail to explain whatthe FTSC coukd have done to relieve the prolems wth metered connections.
MvdV>> You have failed to make me understand .
MvdV>> No, that was not the example given, I have lost you..
ml> when i mentioned the Txy flags possibility of usage with positional ml> INA or other protocol flags, that example was by connection system... ml> apparently we lost each other...
I still do not see how that solves the problems with metered connections.
ml>> i disagree... it is the dumbing down of and especially the ml>> failure of newer software to even touch the capabilities of the ml>> traditional software used in the heyday of FTN...
MvdV>> And yet the network works very well without all that antiquated MvdV>> stuff...
ml> LOLOLOL!! if one didn't know better, one might think that binkd was ml> older than its parent binkleyterm which does more than binkd does (eg: ml> event scheduling) ;)
Event scheduling is no longer needed. The modern OS's all have buid in schedulers (Windows calls it that task manager) that are far more flexible than what I have ever seen in a mailer. InterMail's event manager does not look furher ahead that a week. The window task manager can schedule an event on 03:00 on the last Sunday in October (end of DST). Or every second Monday in June, July and August.
Swiss Army knives are usefull when you are on the road. In the workshop, you are better of with a dedicated tool for each job.
MvdV>>> The popularity of binkd can be partly ascribed to it NOT being MvdV>>> a Swiss army knife and only covering the basics needed to MvdV>>> exchange files between systems.
ml>> yet, it emphasizes, enhances and extends the moniker of ml>> "blackhole mailer" that was earned by its parent...
MvdV>> Unjustified...
ml> no, it is not...
Yes it is. See above about lookingat it with the right glasses.
ml> it stems from numerous problems with the way it operates...
Only for those that can't get rid of their FD style way of looking at things.
ml> run it as a daemon and tell me how you can tell when there is mail ml> sitting in an outbound directory that's not going to go anywhere...
DIR *.?lo
MvdV>> Black holes in Fidonet are found where sysops have made their MvdV>> systems so complicated that they have lost track and no longer MvdV>> know what is under the hood.
ml> no... blackholes happen for various reasons... typo problems are one ml> where an address may be mistyped... then there are routings where a ml> node disappears that may have been a routing bridge and no one goes ml> back or even knows how to unpack the netmail waiting for that gone ml> node and reroute it via another system so that it can be sent on to ml> the destination OR to even be bounced back to the originating system ml> so they will know that something is broken in the routing...
All that can be done with BSO as well as with AMA. In both cases one needs to know how the system operates.
ml> we've seen, in recent months, several blackholes and those on the most ml> simple of system configurations...
