Text 1299, 171 rader
Skriven 2012-07-26 14:18:05 av mark lewis (1:3634/12.0)
   Kommentar till text 1265 av Michiel van der Vlist (2:280/5555)
Ärende: dupes!
==============
 MvdV>> Yes, so called fully connected polygons use the seen-by to
 MvdV>> prevent messages running around in circles. But if susch a
 MvdV>> polygon crosses a zone boundery and the zone crossing link
 MvdV>> strips the seen by, that doesn't work any more.

 ml> right... this is why we have set them up as a "dumbbell" shape in the
 ml> past...

 MvdV> With only ONE bridge between the islands...

and? your problem is?

 MvdV>> For a 3 node ring, one can get away with tiny seen-by
 MvdV>> (stripping all but the own node number and those of the direct
 MvdV>> links) but for a four or more node polygon that does not work.

 MvdV> The context was "zone crossing fully connected polygons". So the
 MvdV> above is to be read as:

i know...

 MvdV>> For a 3 node zone crossing ring, one can get away with tiny seen-by
 MvdV>> (stripping all but the own node number and those of the direct
 MvdV>> links) but for a four or more node zone crossing polygon that does
 MvdV>> not work.

right... there was never a specific design policy or layout that i'm aware
of... AFAIK, it has always been more of each zone has its own distribution
system and those systems are linked by bridge systems who do all the heavy
hauling across the various ponds...

 ml> here in Z1, we had a backbone that was made of 5 or 6 systems in a
 ml> fully connected polygon...

 MvdV> But not zone crossing...

never intended to be... however the WWB was a zone crosser... i don't know what
their layout was, though... i was a member of it and the Z1B... the WWB was
more hands off on control... when new areas were added to the Z1B, they were
also added to the WWB... when areas were removed from the Z1B, they were also
removed from the WWB... IIRC, the WWB originated in Z3 but i'd have to go dig
to see if i still have that info...

 ml> it worked just fine and messages were delivered very rapidly thru the
 ml> polygon... then, between the NAB and the Z1B there was one system that
 ml> was a member of both... that system handled the passing of the traffic
 ml> between the 'bones... this would be similar to one system in one zone
 ml> and one system in another zone...

 MvdV> However as noted above, one can only have ONE bridge between the
 MvdV> zones. If zone B connects to zones A and C, one can not also have
 MvdV> a bridge between A and C. So all traffic between A and C goes via
 MvdV> B.

yes, you can have bridges between all three... but one or more systems will be
eating dupes...

 MvdV> And then when something happens to B, A and C are isolated from
 MvdV> each other. This is exactly what happened when the NAB set all
 MvdV> outside of Z1 to read only. Islands outside Z1 that connected to
 MvdV> the NAB were isolated from each other. 

 MvdV> This must never ever happen again. No distributor should ever
 MvdV> again have that power.

i understand... however, it is much too late to fix, is it not? i'm not giving
up my well known and tested mail tosser for something quite unknown, untested
and with less features...

 MvdV>> This crappy system with 2D seen-by and path in a 3D environment
 MvdV>> and cross zone SEEN+BY stripping only works as designed when
 MvdV>> zones are connected at ONE place only. It utterly fails when
 MvdV>> there are zone crossing loops.

 ml> there should not be should there?

 MvdV> Yes, to avoid having a single party the power to disrupt global
 MvdV> echomail distribution.

if something breaks, you connect elsewhere... this is a fact of life... ISP
falls over? connect to another one... internet dies and takes your phone, TV
and email with it, use the landline phone...

 MvdV>> But having zones connected at one place - the zonegate - has
 MvdV>> the

 ml> zonegates are something else entirely... zonegates are for netmail not
 ml> echomail...

 MvdV> You take the definition to narrow. I call everyting that bridges
 MvdV> two zones a zonegate.

that is an incorrect definition and always has been... zonegates had a very
narrow function and that's all they did in their zonegate mode of operation...
i'm using the original definition, BTW:... i may even still have some of their
documentation around here that explains it for those who don't know and insist
on using the term incorrectly...

 MvdV>> weakness of placing the distribution at the mercy of the gate
 MvdV>> keeper. Too often sysops of such key systems have abused their
 MvdV>> power. The NAB coup is only the last in a row of major
 MvdV>> incidents in the history of Fidonet.

 ml> you definitely weren't around back in the heyday, then... Z1 had huge
 ml> "discussions" about echomail and those attempting to control it in
 ml> more ways than one...

 MvdV> And you think Z1 is the only place were this happened? take a
 MvdV> wider view. Back in the 90ties we had fierce CSO wars here. As I
 MvdV> was the co-sysop of the Dutch TiptTop gate, I know all about it.

"CSO"??

 MvdV>> This situation is highly undesirable. In the POTS area with sky
 MvdV>> high cost of intercontinental data transport we had little
 MvdV>> choice. But now in the age of the internet, with for all
 MvdV>> practical purposes zero cost of world wide Fidonet
 MvdV>> distribution, we can and should go back to the benign anarchy
 MvdV>> that Fidonet once was.

 ml> agreed to a point... that point being that we must still work together
 ml> for the network to operate smoothly with regard to netmail routing and
 ml> echomail distribution...

 MvdV> The point is that some do not wish to work together, but wish to
 MvdV> impose their will on others. 

this is a fact of life... you are, actually doing just this very thing right
now ;)

 MvdV> So we should go for a distribution algorithm that does not come 
 MvdV> to ascreeching halt when some prty does not want t cooperate and 
 MvdV> impose his/her will on the rest.

cooperation is a two-way street... if one party won't cooperate, that means the
other party is also not cooperating... cooperation means meeting in the middle
ground so that all parties gain some and loose some in roughly equal amounts...

 ml> what is being done about gated echos that are gated by more than one
 ml> system and each has its own method of generating the MSGID on the
 ml> fidonet side? that was a big problem years back...

 MvdV> It appears that it is still a problem...

yes, it is... very much so and it is getting worse and worse every time someone
sets up a new system and starts gating stuff into fidonet or some other
network...

 ml>> <SIGH> SMH

 MvdV>> Sigh as much as you want. It works.

 ml> i'm not sighing about whether the system works to move the mail... i'm
 ml> sighing because you are assigning a reason that doesn't affect the
 ml> system if it exists or not...

 MvdV> Whatever. I am not going to tell you how exactly the NADS works.
 MvdV> You seem to think that we are all idiots that know nothing about

don't put words in my mouth...

 MvdV> echomail distribution and the problems that can arise when
 MvdV> parties do not wish to cooperate but wish to dominate instead.
 MvdV> Figure it out for yourself, you are the know it all. 

and there you go pushing other interested parties away... you would do well to
go ahead and pull the trigger... you still have 10 toes to shoot off :/

)\/(ark

 * Origin:  (1:3634/12)