Text 7378, 167 rader
Skriven 2014-10-05 12:21:36 av mark lewis (1:3634/12.0)
Kommentar till text 7376 av Michiel van der Vlist (2:280/5555)
Ärende: FTSC-5001 question
==========================
On Sun, 05 Oct 2014, Michiel van der Vlist wrote to mark lewis:
ml> eg:
ml> ,12,some_system,some_location,a_sysop,#-###-###-####,33600,XA,V34,CM,
ml> / ITN,IVM, / INA:site1.tld,IBN, / INA:site2.tld,ITN,
ml> / INA:site3.tld,IBN,ITN,IVM, / PING
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:
MvdV> ,12,some_system,some_location,a_sysop,#-###-###-####,33600,XA,V34
MvdV> ,CM, INA:site3.tld,IBN,ITN,IVM,IBN:site1.tld,ITN:site2.tld,PING
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...
)\/(ark
* Origin: (1:3634/12)
|