Text 10530, 228 rader
Skriven 2010-09-19 16:05:52 av Richard Webb (1:116/901.0)
Kommentar till en text av Michiel van der Vlist (2:280/5555)
Ärende: PVT Nodes
=================
Hello Michiel,
On Sun 2038-Sep-19 13:51, Michiel van der Vlist (2:280/5555) wrote to Richard
Webb:
<snip>
MvdV> So we agree that Fidoenet was designed as a peer to peer network
MvdV> and that the original idea was that every node should be able to
MvdV> connect to every other node...
OF course, that's what there was.
RW> But, and if I'm remembering right I've seen this circular argument
RW> before, but ...
MvdV> I see no circularity and the argument, but yes.. it has come up
MvdV> before.
Circular as in it goes around and around with points of
disagreement still remaining points of disagreement.
Nothing gets resolved.
RW> HOw does a node that only communicates via pots communicate
RW> directly with a telnet only node? How about a node that can
RW> communicate only via email tunneling and a binkd node?
MvdV> That is not possible of course.
true, but all of those connection schemes were developed for versatility.
NOte your points on standards even in the pots days re
modems etc. YEs that was a problem then, soon resolved in
many situations.
<some good points snipped>
MvdV> All true. But it is a long way from striving for universal
MvdV> connectivity and not reaching a 100% to knowingly and willingly
MvdV> throwing it overboard by reducing the requirement of being ablke
MvdV> to receive mail during ZMH by adding "from his NC".
ACknowledged and granted. But, moot for the email tunneling connected node,
etc.
RW> I always said even back in the halcyon days of this network
RW> that it was reliable routing as well as the p2p component of Fido that
RW> would keep it viable.
MvdV> Of course. Reliable routing is ALSO important for the viability of
MvdV> the network. OTOH it should be clear that the network can not
MvdV> function on routing alone or at least will become very vulnerable
MvdV> for single point of failure. If a substantial amount of nodes can
MvdV> only be reached via routed mail, a large portion of the network
MvdV> can become unreacheble by the failure of one or a few nodes doing
MvdV> the routing. A node that can not be reached directly, is
MvdV> unreacheable if his uplink goes down.
True, and part of the battle I'm fighting in the ham radio
world. Emergency comms folks have grown accustomed to
thinking long haul traffic capability is a moot point,
because even though the town or other political entity might be without all
this infrastructure next town over has
everything still. So everybody from public safety comms
folks to the hams who are supposed to be the backup plan
think in terms of a vhf antenna on a temporary mast, reach
out and touch next county or town, snap fingers, you're
connected again. Tain't necessarily so! A Katrina, or the
shrugging of the NEw Madrid fault and ... you can guess the
rest.
This is also why I"ve been doing a bit of boosterism on a
cooperative of pots connected folks here in z1 who can
restore some routing capability if a major internet player
happens to crump. WHen Janis had her major outage a year or so back I offered
to step into the brink, restoring her
backbone connections. Problem I've had with my little idea
though is too few nodes out west with pots who've responded. Restoring the
connection between her and ROss is a snap, she connects to me, I connect to
Mark LEwis, Mark connects to
ROss. PUtting the big hubs out wste back in the scheme
though is a bit more difficult <grin>.
MvdV> Plus of course, sometimes one wants some privacy. In the past I
MvdV> have often used crasmail for the sole reason that I did not want
MvdV> my mail to be read by others. Some others in particular.
<rotfl> Understand that one. YEah there's always pgp and
other such encryption schemes, but according to strict
reading of policy they're verboten as well unless all those
in the routing path agree to route encrypted traffic.
RW> We have evolved quite a bit since the days of the founding
RW> fathers of Fido. A good number of connection schemes, all
RW> incompatible with each other.
MvdV> Which is a mixed blessing and partly unneeded.
True, but take away any of those connection schemes and you
deny some nodes connectivity in any form. I haven't ever
really tried to parse the nodelist to see how many are email tunneling only,
how many pots only, etc. wOuld be an
interesting exercise, especially for a snooze article for
somebody <hint hint>.
MvdV> To let go of universal connectivity, or at least compromise a bit
MvdV> will be unavoidable in the not too distant future becuase the
MvdV> telcos are outphasing analog telephony in favour of tne Next
MvdV> Generation Network (NGN). NGN will no longer reliably support our
MvdV> classic modem signals. It is already happening here in Western
MvdV> Europe. POTS is on the way out.
YEs, and we lose a lot there. THere again see the single
point of failure argument we both have espoused.
Also note I agree with you on letting go of universal
connectivity and the "precedents" of the day with isdn only, etc.
Experimentation is how we evolve and grow in any
endeavor, but when those experiments set precedents too
early ... TAke for example the adoption of single sideband
in the utility communications and ham radio world. An am
station could still communicate with an ssb station. LIsten with bfo engaged,
transmit one's full carrier with two
sidebands signal. YEs transmitting one's am signal with
both independent sidebands and carrier is probably going to
make some adjacent folks a bit unhappy, but one *can*
communicate. But, once everybody's gone digital with their
audio anybody who adopts the nonadopted scheme will be shut
out.
tHen there's the great iboc standard set for am broadcasting over on this side
of the pond. Degraded performance for
everybody!
<snip>
MvdV> And now... we have saddled ourselves with not one arternative
MvdV> connection method for POTS, we have half a dozen mutually
MvdV> incompatible connection methods that make use of the InterNet. It
MvdV> is a pity we could never agree on a common connection method for
MvdV> fido overt the internet. As I see it, have multiple incompatible
MvdV> ways to connect is DETRIMENTAL to connectivity.
OF course it is, but, the way the whole system evolved
almost required it. SOme folks couldn't get their mailers
to play virtual modem over the internet, but could handle
email tunneling, others might not have the telnet capability with their
standard mailers but could make use of binkd and
its variants, etc. IN the name of all inclusive nobody gets shut out we may
have, in the long run shot ourselves in the
foot. tHe best defense against this is those systems which
offer a variety of ways to connect, i.e. pots; binkd;
telnet; ftp. sYstems with enough horsepower can offer
multiple connection schemes, and can then with some
willingness to do it stand in the gaps.
<snip other points of agreement>
RW> but, p1-p4 have not evolved with the evolution of FIdonet.
MvdV> Regarding coinnection methods, it is not P4 that has to evolve. P4
MvdV> states one must be able to recive and send mail via FTS-0001 but
MvdV> allows for having the minimum required protocol changed through
MvdV> the FTSC. Unfortunately their are other hurdles on that road...
MvdV> :-(
YEp, that's a job for you ftsc folks <grin>.
MvdV> Many thing just work better if one can agree on a few things. How
MvdV> would the roads look like if we could not agree which side to
MvdV> drive on and we settled for agreeing to disagree?
AGain a point of agreement. But, in this case, we have to
go from where we are, and that was what we were given, an
agreement to disagree. IT's up to current fido folks to
sort it out, and, the place for that, as you noted, is the
ftsc.
RW> I've maintained for years that this "agree to disagree" did
RW> as much as anything to bring about the rapid decline of
RW> Fido, at just the time when internet access was becoming
RW> more widely available and these various connection schemes
RW> were just coming into wide acceptance. All one need to do
RW> to see the basis for my position there is review back issues of
RW> FIdonews.
MvdV> Possibly. "Agree to disagree" certainly did not help and still
MvdV> does not help in keeping FidoNet together. OTOH, I do not think
MvdV> FidoNet could have been "saved" by better coordination and
MvdV> agreeing on standards. FidoNet served a purpose of affordable
MvdV> access to a world wide network for lots of individuals. And then
MvdV> something better came up. Better for most anyway.
YOu might be right there, but for many even when I took my
node down in Iowa fidonet was still the only low cost method of access to the
world of computer comms. When I've had
difficulties with phone lines here fido mail was reliable,
including gated internet email, where my internet connection bombed out because
of the phone line situation. THe robust
protocols offered by zedzap, aborted transfer resume etc.
got me my mail. IT took over a month to get the telco to
respond with a competent technician that time, but for those who needed to get
mail to me my friendly inet to fido
gateway provider filled the gap nicely!
RW> FUny thing, but I'm fighting much the same battle with another
RW> communications service right now, also operated as a volunteer
RW> effort.
MvdV> I have been a ham sinds 1964. Was the caretaker of the local 2m
MvdV> repeater for almost two decades. Now I let the younger generation
MvdV> take care of those things.
<rotfl>. I've done a little of that, but I'm more involved
in the long haul stuff, assisting vessels at sea,
missionaries abroad, and of course domestic long haul
emergency comms using hf. DOn't know if you're connected to ham-fdn but I've
published a couple drafts of a white paper
there on retolling arrl's long haul systems for the future.
IN fact, I just sent draft 6.0 to the coordinator last
night, so it should be hatched into the distribution
pipeline soon, if major file movers have "replace" turned on in their tic
processors <grin>.
MvdV> Cheers, Michiel (PA0MMV)
73 de nf5b
Regards,
Richard
... 10% of everything isn't crap, watch closely or you'll miss it!
--- timEd 1.10.y2k+
* Origin: (1:116/901)
|