rns.recipes

Hi,

I'm not sure to understand :

In a mesh network composed of LoRa nodes, I don't see a purpose for not setting the node as transport node. I mean, if it's a mesh then all the nodes will need to permit other nodes to go through them.

Is that right or did I miss something ?

And in case all the nodes of the mesh act as transport node, then in what mode should they be to make sure they actually relay all the useful information for everyone (announces, links, I don't really know ...) ?

My guess would be gateway, but I'm not sure.

So, all the nodes should be transports in gateway mode on a LoRa mesh ?
Probably not, I'm sure there are some situations I'm not anticipating or edge cases.

Please give me some hints / advices.

Thanks,
Tukan

Right now, yea, every new Rnode is useful as it expand the network, so if your node is gonna average even a few hours of uptime a day then I'd make a transport node.

Read https://github.com/markqvist/Reticulum/discussions/422 if you wanna see why most people shouldn't be a transport node, but that's more in the context of backbone and tcp where you can connect to hundreds of possible servers, LoRa is different because you might be the only one serving your local area and thus your contribution then actually matters because you are the only possible connection.

My guess would be gateway, but I'm not sure.

I personally gravitate to using gateway but some people would argue that access point or boundary is better as they don't flood your area's LoRa band with announcements that nobody is probably listening to (2% of the bandwidth), probably only a concern if you had a lot of LoRa nodes in one spot however. And then use roaming if your node is mobile one ofc.

And if you want people to use your interface, set up https://markqvist.github.io/Reticulum/manual/interfaces.html#discoverable-interfaces so that people can find your node on http://rmap.world or https://rns.fyi because people can't use a node they don't know exists (or that they don't know the exact bandwidth and frequency for, it varies a lot so the chance someone finds it by accident is very low)

Thanks welo, that's really helpful.

That all seems very logical to my mind.

But, then come the doubts :

First, the discussion you mention says (quoting Mark) :

There's a physical limit too, in terms of how many nodes your network can now support, which gets
exponentially smaller when your medium speed drops. Goodbye to using LoRa and similar.

I believe he says that in relation to the transport nodes.

Then the other doubt is about the mode: You says you tend to use gateway. Which is what comes to my mind too.
But I would like to use the mode that lets through only what is actually needed for peers to actually work on a network by their own.
And I don't know what is that mode. I can read about the different modes in the doc, but what is actually needed for a network node to function properly by its own ? And what is the corresponding mode ?

Tukan wrote:

First, the discussion you mention says (quoting Mark) :
> There's a physical limit too, in terms of how many nodes your network can now support, which gets
> exponentially smaller when your medium speed drops. Goodbye to using LoRa and similar.
I believe he says that in relation to the transport nodes.

Yes this would be true if where you live already had 10 Rnodes near by that you could just connect to, in that case making your node a transport node would only add overhead and not provide any benefit and so just being a client and connecting without transporting makes more sense. But I'm guessing that in your local area you are either the only Rnode or only one of few so don't worry about it.

But I would like to use the mode that lets through only what is actually needed for peers to actually work on a network by their own.
And I don't know what is that mode. I can read about the different modes in the doc, but what is actually needed for a network node to function properly by its own ? And what is the corresponding mode?

As long as you're a transport node, any of the modes let other people use your LoRa connection to reach the rest of the network. The only difference between them is how announcements are handled, any mode can allow data to be transported through it http://reticulum.i2p/manual/understanding.html#announce-propagation-rules (roaming and gateway some additional changes but they are pretty minor for an Rnode). If you wanna be safe just set your rnode to boundary rather than gateway but don't worry about it too hard, it doesn't make a big difference really, and the difference it does have only applies if there's other Rnodes near you.

Thank you welo ! That makes things a lot clearer now.

We are between 3 and 5 LoRa nodes where I live, depending on how people feel that day.
And those nodes can come and go, and also move sometimes. So following your guidelines will be helpful.
I also feel like understanding precisely what the different modes do and how they apply.

I also feel like understanding precisely what the different modes do and how they apply.

manual in this specific part explains it better than I ever could https://reticulum.network/manual/interfaces.html#interfaces-modes

Thanks for the link. I regularly get back to it. And I think I understand the theory.
But I need to grasp the actual use of the various modes in various situations.

I must admit that I would be curious to read about a few examples of how existing networks are configured, along with the benefits it generates in the field.
But I guess I will learn more by experimenting myself.

according to the docs, I'd set the rnode transfer=yes and mode=access_point. You probably don't want announces flooding through the mesh, e.g. when your rnode is connected to a gateway/backbone that sends many announces in all directions.