Last night I modified the network to allow any node to host an area. Yes
I stole that idea from WWIVnet.
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... :)
Last night I modified the network to allow any node to host an area. Yes
I stole that idea from WWIVnet.
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 :)
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 :)
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.
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.
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.
that sounds like pass through areas in Fido parlance...
that sounds like pass through areas in Fido parlance...
I don't know what pass through areas are in fidonet.
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.
apam wrote to Avon <=-
that sounds like pass through areas in Fido parlance...
I don't know what pass through areas are in fidonet.
yep what he said ;-)
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 ;-)
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 :)
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.
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?
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
If that's the case it still seems to me to be a slightly weaker w
run things. In fsxNet all the HUBs are fully meshed so although d
Not if you like moderated echos.
What exactly do you mean by moderated echos? Are messages themselves moderated and approved before going out on the area, or just who can connect to the area itself?
It all sounds a bit heavy to me... and given todays climate of nodes
opting for multiple feeds of the same echoarea .. the idea of locking
out someone via a feed cut seems largely nonsensical.
apam wrote to Avon on 05-28-18 14:23 <=-
It all sounds a bit heavy to me... and given todays climate of nodes
opting for multiple feeds of the same echoarea .. the idea of locking
out someone via a feed cut seems largely nonsensical.
Perhaps, but say someone wanted an area for just them and their
friends, they could whitelist only their friends nodes. Assuming they
kept their area available to only a select group on the BBSes,
otherwise anyone could post by connecting to their BBS.
Quoting apam to Blue White <=-
What exactly do you mean by moderated echos? Are messages themselves moderated and approved before going out on the area, or just who can
What exactly do you mean by moderated echos? Are messages themselves moderated and approved before going out on the area, or just who can connect to the area itself?
I've just done some work to hopefully do the latter, so that nodes that can connect to your area can be blacklisted or whitelisted. As for a moderator approving every post, it could be done I suppose, but seems
like a lot of work.
| Sysop: | altere |
|---|---|
| Location: | Houston, TX |
| Users: | 60 |
| Nodes: | 4 (0 / 4) |
| Uptime: | 31:03:24 |
| Calls: | 516 |
| Files: | 6,995 |
| D/L today: |
3 files (36K bytes) |
| Messages: | 289,296 |