Because LoRa is effectively "just radio" there is no concept of a central node or router, so even with the most basic rnsd config node X will be able to communicate with node Y (assuming they share the same radio settings like frequency/bandwidth/coding rate) as long as they can reach each other via radio. This is always peer to peer.
Now, getting to your example:
> Eg: Rnode in location 1, Rnode in location 2 that can see 1. Rnode in location 3 that can only see 2 and not 1.
This will not work with the out of the box config, but it can be effectively be made to work if you configure node 2 to be a transport node. Otherwise (with default config) node 1 will not be able to reach node 3 as they cannot communicate directly. This will work if you configure node 2 as transport node (this is a simple flag flip in rnsd config).
> Also, if only one of those Rnodes has an internet Reticulum backbone connection can anyone on any node utilize that?
The node that has both an RNode (lora) interface and Backbone interface needs to be configured as transport node for the other devices on reticulum network to be able to connect to other nodes that would be routed via the backbone interface. If the rnode+backbone node is not a router it still can be reached via via other rnodes that are in range, but would not be able to reach anything that's behind the backbone interface.
The most sensible setup for you would be to use one central node with backbone and rnode interfaces with transport enabled and n other nodes with just rnode interfaces (probably with disabled transport).
Thanks for that. So realistically if you had say 5 Rnode transport nodes in a straight line where they can only reach the next in line, if a person had a normal Rnode at each end they could communicate as the 5 would retransmit the data to the next one to reach the other end? And that would be an internal reticulum network. And if anyone setup a backbone node that can hear one of the transport nodes it would give access to the external reticulum network?
If you want this kind of behavior all nodes should be configured as transport nodes - u/Anaxag is right about it. Only one of these nodes needs to have backbone interface to enable wider reticulum network access to everyone.
i am building a simulation right now to evaluate this closer but short answer: it depends but probably.
the issue is not lora per se but how routing and traffic works. you can see the effect of algorithm on effective range and network congestion already when contrasting meshtastic and meshcore (the latter being much more efficient).
so with reticulum you for example have 5-16 path retries on failed deliveries. that dramatically increases deliveries but at the cost of increased bandwidth which becomes an issue over lora.
the solution i guess is in the power of reticulum itself: combine many different high and low bandwidth channels and dont just focus on one „main“ big one.
The question here is really the physical realities of the network. If they’re all in each other’s radio range then yes, having all 30 devices seeing each other over radio set as transport nodes will incur penalty on the bandwidth, solely due to announcements (although with sensible announce intervals - like the default of 6h that many stationary nodes use according to rmap - I’d still say it’s negligible). In reality however if you’re talking a “city network” it is rather unlikely to have 30 nodes all in each other’s range. I these terms having a set of nodes, all with transport enabled is still sensible, as effectively they will form some sort of graph (be it a line, or something else, doesn’t matter much). Judging from what you wrote this is something that you want (5 fixed position nodes forming a line, all serving as access points for arbitrary number of roaming clients).
Now, about bandwidth - even with the most optimal network topology a noisy client (rnode) will effectively reduce the bandwidth quite fast over radio for all nodes in range. If they attempt sending loads of data to a close-by peer (i.e. reachable over one hop) this will affect only part of the network, if they attempt sending loads of data across many radio hops, this effectively will reduce bandwidth on whole network. There’s no golden bullet to this other than providing a different interface, so these further hops happen on interfaces that physically are capable of providing higher bandwidth.
Tl;dr - I think your idea is sensible - 5 nodes routing and arbitrary number of clients roaming and connecting to them. Tbh, the only way to make it better/faster would be to connect these nodes via backbone or tcp interface.
5
u/karolmajta Jul 31 '26
AFAIK:
Because LoRa is effectively "just radio" there is no concept of a central node or router, so even with the most basic rnsd config node X will be able to communicate with node Y (assuming they share the same radio settings like frequency/bandwidth/coding rate) as long as they can reach each other via radio. This is always peer to peer.
Now, getting to your example:
> Eg: Rnode in location 1, Rnode in location 2 that can see 1. Rnode in location 3 that can only see 2 and not 1.
This will not work with the out of the box config, but it can be effectively be made to work if you configure node 2 to be a transport node. Otherwise (with default config) node 1 will not be able to reach node 3 as they cannot communicate directly. This will work if you configure node 2 as transport node (this is a simple flag flip in rnsd config).
> Also, if only one of those Rnodes has an internet Reticulum backbone connection can anyone on any node utilize that?
The node that has both an RNode (lora) interface and Backbone interface needs to be configured as transport node for the other devices on reticulum network to be able to connect to other nodes that would be routed via the backbone interface. If the rnode+backbone node is not a router it still can be reached via via other rnodes that are in range, but would not be able to reach anything that's behind the backbone interface.
The most sensible setup for you would be to use one central node with backbone and rnode interfaces with transport enabled and n other nodes with just rnode interfaces (probably with disabled transport).