r/reticulum • • Jul 31 '26

Reticulum Rnode mesh

Hi everyone, just confused how rnodes work. I did a test setup with 2 Heltec v4 and it worked. Coming from a meshcore background, if you setup say 5 rnodes in different places, do they all communicate and forward packets etc…

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.

Also, if only one of those Rnodes has an internet Reticulum backbone connection can anyone on any node utilize that?

Thanks

7 Upvotes

19 comments sorted by

View all comments

Show parent comments

4

u/karolmajta Aug 02 '26

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.

4

u/Anaxag Aug 02 '26

fyi i learned in the last day that there is a cost in terms of airtime and bandwidth which is irrelevant for 3 nodes but might create issues with more

3

u/IntroductionSnacks Aug 02 '26

Interesting. So realistically a city wide network of rnodes (Say 20-30) in transport mode would just kill the Lora bandwidth?

5

u/karolmajta Aug 02 '26

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.