ml> in the above: ml> 1. the first ITN,IVM apply to the f.n.z.domain.tld converted ml> connection address because there is no FQDN or IP number listed.
MvdV> That is a nono. After the folding of fidonet.net the Fidonet MvdV> community realised that depening on a third party over which MvdV> Fidonet has no control is a bad idea.
that's fidonet... other FTNs do use such and there is the binkp.net which is used by default by a very widely used mailer... that mailer looks up everything and i've not yet found any way to stop it from doing any DNS lookups other than that required for the initial outbound connection... all connections results in numerous to many DNS lookups... especially inbound connections and even moreso those that present large AKA lists... every one of those addresses is looked up and several times during the same connection in some cases...
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 documenetd MvdV> in FTS-5004 are an /additional/ service, not a replacement for MvdV> the nodelist.
agreed on both accounts...
ml> 2. the first IBN applies only to site1.tld. there is no ITN or IVM ml> there and the f.n.z.domain.tld doesn't handle it at all.
MvdV> DNS distributed nodelists are a third part service. The Fidonet MvdV> nodelist clerks have no control over it. They can not stop the MvdV> operator of that service to include it,.
true... the way that line was laid out used the f.n.z because there's no IP or FQDN in the "system name" field so that flag was useless up to that point if the f.n.z was not performed...
ml> 3. the second ITN applies only to site2.tld. there is no IBN or IVM ml> there.
ml> 4. the fourth site, site3.tld, handles all three connection types.
MvdV> I have tried ro reverse engineer it back into a real physical MvdV> system and with the exception of 1, I got something that MvdV> translates back into a FTS-5000/FTS5001 compatible nodelist line MvdV> as follows:
i guess that would work... the question is if all nodelist parsing software will handle it correctly...
MvdV> It is a mystery to me why anyone would compose such an exotic MvdV> system.
connection limitations is one of the first that come to mind... in the original example, site3 was to be a final backup if the others could not be reached...
MvdV> Why on earth would anyone with a multihomed connection - MvdV> IBN is reachable via two different paths and so is ITN, so the MvdV> system is multihomed - only make some servers available via MvdV> multihoming and some others only via one path?
again, ISP connection limitations is the first thing that comes to mind... we tested a wireless ISP a while back and there were problems staying connected that were out of their hands... the person they were leasing the land from had a jealous adult daughter who kept killing the power to the tower equipment on the leased land... she was doing this because she was mad at not getting any of the lease $$$ being paid to her mother, the land owner... when the connection was up, it was great... it was a family thing and the law was not involved between them about it... eventually, the ISP removed their equipment...
we have, at various times, had several feeds into this location... you speak above as if you are thinking about one system (multi-homed) but it is not... each connection has its own firewall and internal routing on the shared internal network... inbound traffic gets sent to the desired internal machine and outbound traffic flows as appropraite... no machines are multi-homed other than a laptop or two and they have nothing to do with any FTN ops...
MvdV> This look like a system with a multi personality disorder. The MvdV> more logical and I also think better way to understand for humans MvdV> is to use more than one node number.
that was considered... the simplistic barely capable routing of today's FTN is a far cry from what we used to have and be able to do... much of what was has been transformed into less capable functionality and too many things have become too simplistic and lost capabilities...
MvdV> This is how it was done in the POTS age when one had more than MvdV> one lines with modems with different capabilities connected.
yes, i remember... we really didn't want to go there... mainly because there's no way to tell that widely used mailer to try to send to a different system when connections with one fail X times... it does easily try multiple IPs/FQDNs specified in the remote systems connection definition line, though...
besides, how many out there really know how to use bonk, SonOfBonk or similar tools that /might/ be able to unpack mail and repack it to another system? how many really understand why that is done? especially those that are converted from dynamic mailers like frontdoor, intermail and (i'm guessing) IREX which do all of this for you in the background... the network has gone backwards in a bad way :/
ml> intelligent mailers and nodelist using software would have no problem ml> with this... it should also allow for the Xx flags to be listed with ml> each as well as pretty much all other flags... i can easily see the ml> Txy flags being listed with INA flags indicating that sitex.tld is ml> operational at certain times...
MvdV> Another one of your unrealistic exotic scenerios.
bite me... it is not un-realistic... see the above about ISP connection limitations and consider metered connections...
MvdV> "Smooth operation of the network" is not served by building MvdV> system with excotic combinations of on-line times.
that's not my problem... the capability exists and is used when desired... fuss at those guys from yesteryear who created the capability and implementation...
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.
respectfulyl, that is shortsighted and incorrect... see above about ISP connection limitations and metering...
MvdV> A classic POTS line can handle just one connection per physical MvdV> line. Internet connection do not have that limitation. One MvdV> physical line can carry many connection, so time sharing between MvdV> services is not needed. All services can use the line MvdV> simultaneously at all times.
you misunderstand the reason for limited online times in today's world...
MvdV> Limiting time depending on service makes no sense.
i don't know what you mean buy this... the example given was to limit online time by system (aka nodenumber)...
ml> the sad thing is that the intelligence that mailer software used to ml> have has been lost...
MvdV> It is those that demand that the systems covers more and more MvdV> protocols in exotic scenarios that are partly to blame for that.
i disagree... it is the dumbing down of and especially the failure of newer software to even touch the capabilities of the traditional software used in the heyday of FTN...
MvdV> The popularity of binkd can be partly ascribed to it NOT being a MvdV> Swiss army knife and only covering the basics needed to exchange MvdV> files between systems.
yet, it emphasizes, enhances and extends the moniker of "blackhole mailer" that was earned by its parent...
