Hello

Last night I modified the network to allow any node to host an area. Yes
I stole that idea from WWIVnet.

The network still has one hub only and only the hub has downlinks and
downlinks only have one uplink (the hub). So still very simple in this
regard.

If node 2 posts to an area hosted by node 5, a message entered on node 2
would be sent to node 5 via node 1 (the hub), node 5 would then relay the messages to all the other connected nodes also via node 1.

So, now I'm working on the idea, if node 5 vanishes, the messages should
be just discarded, but I think an "Undeliverable" message should be sent
back to the node the originating message was sent from, so they know to
remove that area.

There also needs to be an easy way of managing subscription lists,
something like areafix I suppose.

Anyway. Just thought I'd share :)

Andrew

--- MagickaBBS v0.11alpha (Linux/x86_64)
* Origin: Exotica BBS - telnet://exoticabbs.com:2023/ (21:1/125)

On 05/24/18, apam said the following...

Last night I modified the network to allow any node to host an area. Yes
I stole that idea from WWIVnet.

I find it amazing what you and others are able to program, while I was having issues with sorting records... :)

Keep up the great work!


---

Black Panther
a.k.a. Dan Richter
Sysop - Castle Rock BBS (RCS)
telnet://bbs.castlerockbbs.com
http://www.castlerockbbs.com
The sparrows are flying again....

--- Mystic BBS v1.12 A39 2018/04/21 (Linux/64)
* Origin: Castle Rock BBS - bbs.castlerockbbs.com (21:1/186)

On 05/24/18, apam said the following...

Last night I modified the network to allow any node to host an ar
I stole that idea from WWIVnet.

I find it amazing what you and others are able to program, while I
was having issues with sorting records... :)

I can never remember how to do sorting algorithms, have to google it
every time lol.

Andrew

--- MagickaBBS v0.11alpha (Linux/x86_64)
* Origin: Exotica BBS - telnet://exoticabbs.com:2023/ (21:1/125)

On 05/24/18, apam pondered and said...

Last night I modified the network to allow any node to host an area. Yes
I stole that idea from WWIVnet.

I still need to wrap my head around that mode of operation..

If node 2 posts to an area hosted by node 5, a message entered on node 2 would be sent to node 5 via node 1 (the hub), node 5 would then relay the messages to all the other connected nodes also via node 1.

How does node two know of the area to post to? It seems node one (the HUB) is really doing all the relaying to other nodes anyway so what is the advantage
of a node 'hosting' an area? Is just seems the host is reliant on the HUB anyway? I may misunderstand but curious to learn :)

So, now I'm working on the idea, if node 5 vanishes, the messages should be just discarded, but I think an "Undeliverable" message should be sent back to the node the originating message was sent from, so they know to remove that area.

Yep agreed...

There also needs to be an easy way of managing subscription lists, something like areafix I suppose.

Anyway. Just thought I'd share :)

Yep, else nodes would not know what is available.

--- Mystic BBS v1.12 A39 2018/04/21 (Windows/32)
* Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)

On 05/24/18, apam said the following...

Last night I modified the network to allow any node to host an area. Yes
I stole that idea from WWIVnet.

That's an exciting idea to be honest. It would bring some flavor from individual boards onto the overall network, and maybe make folks feel more
like a part of the network rather than just being endpoints.

--- Mystic BBS v1.12 A39 2018/04/21 (Raspberry Pi/32)
* Origin: Alcoholiday / Est. 1995 / alco.bbs.io (21:1/113)

If node 2 posts to an area hosted by node 5, a message entered on would be sent to node 5 via node 1 (the hub), node 5 would then r messages to all the other connected nodes also via node 1.

How does node two know of the area to post to? It seems node one (the
HUB) is really doing all the relaying to other nodes anyway so what
is the advantage of a node 'hosting' an area? Is just seems the host
is reliant on the HUB anyway? I may misunderstand but curious to
learn :)

Weatherman or Rushfan may be able to answer that better than me..

The hub doesn't know about areas it isn't joined to, it just sees
messages not for it and forwards them along.

It means if node 4,5,6 are interested in cooking for example, and the hub isn't, and for whatever reason doesn't want to host a cooking area, a
node could host it instead. the node is responsible for maintaining the subscription list, but the messages are relayed by the in-place
infrastructure.

It means they don't have either create their own network or setup
different polling operations.

Andrew

--- MagickaBBS v0.11alpha (Linux/x86_64)
* Origin: Exotica BBS - telnet://exoticabbs.com:2023/ (21:1/125)

On 05/24/18, apam said the following...

Last night I modified the network to allow any node to host an ar
I stole that idea from WWIVnet.

That's an exciting idea to be honest. It would bring some flavor from individual boards onto the overall network, and maybe make folks feel
more like a part of the network rather than just being endpoints.

WWIVnet is a pretty impressive thing, I probably should have just worked
on re-intergrating WWIVnet into Magicka (I used to have WWIVnet and FTN,
but my implementation was pretty flakey, and I eventually removed it when WWIVnet-FTN became available).

Andrew

--- MagickaBBS v0.11alpha (Linux/x86_64)
* Origin: Exotica BBS - telnet://exoticabbs.com:2023/ (21:1/125)

On 05/24/18, apam said the following...

WWIVnet is a pretty impressive thing, I probably should have just worked on re-intergrating WWIVnet into Magicka (I used to have WWIVnet and FTN, but my implementation was pretty flakey, and I eventually removed it when WWIVnet-FTN became available).

I have a soft spot for WWIVnet. I have the FTN WWIVnet on my board, but I
also have a WWIV board connected to WWIVnet the traditional way. It's always been a very cool networking system.

--- Mystic BBS v1.12 A39 2018/04/21 (Raspberry Pi/32)
* Origin: Alcoholiday / Est. 1995 / alco.bbs.io (21:1/113)

On 05/24/18, apam pondered and said...

The hub doesn't know about areas it isn't joined to, it just sees
messages not for it and forwards them along.

OK

It means if node 4,5,6 are interested in cooking for example, and the hub isn't, and for whatever reason doesn't want to host a cooking area, a
node could host it instead. the node is responsible for maintaining the subscription list, but the messages are relayed by the in-place infrastructure.

OK thanks, that helps, so in sum the whole network is aware of all nodes but nodes can generate their own message areas (echomail bases) and offer them to all nodes to link to or not. A HUB (which I still struggle with in this
network description) can just act as a forwarding system that shares interconnections with nodes but not necessarily carry any/all of the message areas passing between it and the nodes... that sounds like pass through areas in Fido parlance...

--- Mystic BBS v1.12 A39 2018/04/21 (Windows/32)
* Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)

OK thanks, that helps, so in sum the whole network is aware of all
nodes

Only the hub is aware of all nodes. The hosts of echo areas are aware of
all nodes connected to the echo area.

but nodes can generate their own message areas (echomail bases)
and offer them to all nodes to link to or not.

Yep.

Let's say I'm node 4 and want to connect to an area hosted by node 3. I
send a subscription message for node 3 saying I want to connect to area X
to node 1. Node 1 sees a message for node 3 and sends it to node 3. Node
3 adds me to the list and I am connected.

Now say I post a message. My message gets sent to node 1, node 1 then
sends it to node 3, who then sends messages to all connected nodes via
node 1.

All messages pass through node 1.

that sounds like pass through areas in Fido parlance...

I don't know what pass through areas are in fidonet.

Andrew


--- MagickaBBS v0.11alpha (Linux/x86_64)
* Origin: Exotica BBS - telnet://exoticabbs.com:2023/ (21:1/125)

Re: Re: Day 3: Network Experiments
By: apam to Avon on Thu May 24 2018 07:28 pm

that sounds like pass through areas in Fido parlance...

I don't know what pass through areas are in fidonet.

A node may accept messages in a passthrough area and pass it on to connected nodes but doesn't store the messages in the local message base.

Some hubs have access to many areas they aren't connected too but if a link connects one of those areas it will connect the area and pass traffic on to those connected. Rescaning a passthrough area is not possible since there is no local message base.

Ttyl :-),
Al


... No sense being pessimistic. It wouldn't work anyway.
--- SBBSecho 3.04-Linux
* Origin: The Rusty MailBox - Penticton, BC Canada (21:4/106)

On 05/24/18, Al pondered and said...

connected nodes but doesn't store the messages in the local message base.

Some hubs have access to many areas they aren't connected too but if a link connects one of those areas it will connect the area and pass
traffic on to those connected. Rescaning a passthrough area is not possible since there is no local message base.

yep what he said ;-)

--- Mystic BBS v1.12 A39 2018/04/21 (Windows/32)
* Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)

apam wrote to Avon <=-

that sounds like pass through areas in Fido parlance...

I don't know what pass through areas are in fidonet.

As the name suggests, messages in those areas pass through, but are not tossed into the local BBS - they come in from the uplink, and then are repacked for the downlinks that are connected to the echo.


... When in doubt, predict that the trend will continue.
=== MultiMail/Win32 v0.49
--- SBBSecho 3.03-Linux
* Origin: Freeway BBS Bendigo,Australia freeway.apana.org.au (21:1/109)

Re: Re: Day 3: Network Experiments
By: Avon to Apam on Thu May 24 2018 09:43 pm

yep what he said ;-)

There was a time when I had quite a few passthrough areas.

Going back quite a few years I can remember having 10MB free on the BBS machine.. which had the largest HD in my collection.

As much as I miss those days I can honestly say I don't miss those days. :)

Ttyl :-),
Al


... Our program, who art in memory. EXE be thy name.
--- SBBSecho 3.04-Linux
* Origin: The Rusty MailBox - Penticton, BC Canada (21:4/106)

Some hubs have access to many areas they aren't connected too but
link connects one of those areas it will connect the area and pas traffic on to those connected. Rescaning a passthrough area is no possible since there is no local message base.

yep what he said ;-)

Ah OK. Does sound similar, except the node doing the passthrough would
need to know about the areas it's passing?

Andrew

--- MagickaBBS v0.11alpha (Linux/x86_64)
* Origin: Exotica BBS - telnet://exoticabbs.com:2023/ (21:1/125)

If node 2 posts to an area hosted by node 5, a message entered on node
2 would be sent to node 5 via node 1 (the hub), node 5 would then relay the messages to all the other connected nodes also via node 1.

That sounds a lot like how the GT Power BBS networking used to work with
echos. I liked it because it allowed for moderated echos, and also
eliminated some of the other issues that ftn networks can have. GT Power networking did allow for more than one hub, but the rest sounds familiar.

You would add/remove/etc. echos by sending netmail to the hub with "dot" commands (lines that started with a period).

(dot)GM echonumber[,echodate] <-- "give me" that echo from optional
network julian date

(dot)GQ echonumber <-- quit sending me that echo

(dot)GL <-- get a list of all the echos carried on the system

There were other dot commands, but those are the three that were used most
for echomail.

It was more difficult to create a dupe-loop because accidentally requesting
the same echo from two hubs would cause you to receive two echo packets
that were named the same... IIRC the second one would not unpack.


... 2 + 2 = 5 for extremely large values of 2.
--- MultiMail
* Origin: Possum Lodge South * capitolcityonline.net:7636 (21:1/175.8)

How does node two know of the area to post to? It seems node one (the
HUB) is really doing all the relaying to other nodes anyway so what is
the advantage of a node 'hosting' an area? Is just seems the host is reliant on the HUB anyway? I may misunderstand but curious to learn :)

Moderated echos and better dupe prevention. Probably other benefits, too.
A message does not echo out to the other subscribed nodes until it reaches
the echo host for that echo. That is if I understand it correctly.


... Computer Hacker wanted. Must have own axe.
--- MultiMail
* Origin: Possum Lodge South * capitolcityonline.net:7636 (21:1/175.8)

On 05/24/18, Blue White pondered and said...

Moderated echos and better dupe prevention. Probably other benefits,
too. A message does not echo out to the other subscribed nodes until it reaches the echo host for that echo. That is if I understand it correctly.

If that's the case it still seems to me to be a slightly weaker way to run things. In fsxNet all the HUBs are fully meshed so although dupes are caused
at three HUBs each time something is posted by (lets say) a node in NET 1,
the other NETs have a far better chance of getting the messages with the
other three HUBs also sharing the same traffic between them.

This is something that's been in place for a number of months now with out
any issues (except the high dupe bases at each HUB :)) and has save the bacon
a few times for nodes when a HUB has stopped working for a few hours..

--- Mystic BBS v1.12 A39 2018/04/21 (Windows/32)
* Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)

On 05/24/18, Blue White pondered and said...

Moderated echos and better dupe prevention. Probably other benef
too. A message does not echo out to the other subscribed nodes un reaches the echo host for that echo. That is if I understand it correctly.

If that's the case it still seems to me to be a slightly weaker way
to run things. In fsxNet all the HUBs are fully meshed so although
dupes are caused at three HUBs each time something is posted by (lets
say) a node in NET 1, the other NETs have a far better chance of
getting the messages with the other three HUBs also sharing the same traffic between them.

I guess it really depends on your priorities, and how you rate fault
tolerance. I don't know about GTPower, but in my own system if the hub
rolls over then it's pretty catastrophic. If the node hosting an echo
area disappears, then so does the echo area, so yeah, not very fault
tolerant -- but it's only been 4 days of thinking / implementing :)

FSXnet is better equipped to handle a hub failure as you say, but if one
hub goes out, then a third of the network does too (assuming there are 3
hubs, not counting the frontdoor one).

So ultimately, you need all the nodes to be hubs, and all mesh together
to be fully fault tolerant, I guess that's kind of what you were talking
about the other day with p2p networking.

However, it is my understanding that in this scenario, all nodes need to communicate all traffic to all other nodes else there is a chance for
messages not to turn up?

Andrew

--- MagickaBBS v0.11alpha (Linux/x86_64)
* Origin: Exotica BBS - telnet://exoticabbs.com:2023/ (21:1/125)

On 05/25/18, apam pondered and said...

I guess it really depends on your priorities, and how you rate fault tolerance. I don't know about GTPower, but in my own system if the hub rolls over then it's pretty catastrophic. If the node hosting an echo
area disappears, then so does the echo area, so yeah, not very fault tolerant -- but it's only been 4 days of thinking / implementing :)

Yep gotcha..

FSXnet is better equipped to handle a hub failure as you say, but if one hub goes out, then a third of the network does too (assuming there are 3 hubs, not counting the frontdoor one).

Yep that's right

So ultimately, you need all the nodes to be hubs, and all mesh together
to be fully fault tolerant, I guess that's kind of what you were talking about the other day with p2p networking.

I don't know if all is required but ideally there would be some additional linkages between a few. Indeed the idea might be when a node joins by default it links to either a couple of HUBs and/or a couple of other nodes... I'd say that would surely do it for most nodes to get the redundancy they wanted..

However, it is my understanding that in this scenario, all nodes need to communicate all traffic to all other nodes else there is a chance for messages not to turn up?

Well I guess there's always a chance but in the case of some systems that
have linked to my Fido feed not all echoareas are being fed to them. Those nodes seem to take a view of pulling a mix of echos from a mix of locations
but it's not a 100% mesh thing for a number of them..

Best, Paul

--- Mystic BBS v1.12 A39 2018/04/21 (Windows/32)
* Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)