[Feature Request]: Next Hop Routing

[Ylianst]

I just got into Meshtastic with the main goal to be able to communicate short messages to my wife that works at a local hospital in cases where the cell phone or power infrastructure would go down. This is unlikely to ever happen, but I would like to have it as a backup. I am in the Portland, Oregon area and I see a lot of stations around but the direct messaging experience is poor.

I see this PR: Next Hop-based routing with fallback to flooding and this looks a lot like what I would use. That is, I want to be able to set the exact relay path for a message to use without flooding.

In my view, I would gladly develop a client (on the PC or Phone) that would work to figure out the best path using more CPU & Memory and have the Meshtastic firmware just sent the packet and do relay without trying to have routes be figured out on the smaller device. This could bring a bunch of innovation in this area. Also, in my use case, I would not fallback to flooding. This would also (I would guess) be more spectrum efficient for the area as it would reduce unnecessary message repeats and have a more consistent message path.

So, my questions are:

• Is my usage incompatible with Meshtastic? Are there a better options?
• Is having the PC/Phone do more work to figure out data paths generally regarded as acceptable?
• Any way I can promote next hop routing... would be sweet.

Feedback and comments appreciated.

[GUVWAF]

• Is my usage incompatible with Meshtastic? Are there a better options?

I would never say you can rely on Meshtastic in emergency situations, but that would hold for anything using the ISM bands. It won't ever be military grade, but I don't know of anything else in the same price range that is.

• Is having the PC/Phone do more work to figure out data paths generally regarded as acceptable?

It's doable, but the amount of additional "work" in terms of processing power and memory usage is not your only problem. Considering that you or other nodes are moving around, and weather conditions change, routes need to be discovered and kept alive continuously over the same medium as normal traffic, which eats bandwidth. See also this blog post: https://meshtastic.org/blog/why-meshtastic-uses-managed-flood-routing/

• Any way I can promote next hop routing... would be sweet.

There's (at least) two outstanding considerations that need to be resolved/analyzed first: #2856 (comment). If anyone has any ideas, I'm all ears.

[Ylianst]

Thanks @GUVWAF

I would never say you can rely on Meshtastic in emergency situations

You are absolutely right. I should have said, used as an alternative to typical communication systems in cases where they are not available. Still, having more reliable message passing would be great. By the way, low latency is not a requirement in my case. Having a time stamped message that moves slowly is ok, ham radio operators do practice this form of message passing.

the amount of additional "work" in terms of processing power and memory usage is not your only problem.

Yes, totally on the same page there, this is not a trivial problem at all. Having mesh topology discovery happen along with payload message passing with minimal overhead would be ideal, but this is a very imperfect medium.

There's (at least) two outstanding considerations that need to be resolved/analyzed first: #2856 (comment). If anyone has any ideas, I'm all ears.

If I had to take a guess as a developer (and I may need to be educated on this more), Meshtastic would evolve into a layer 2 communication layer with end nodes having some form of more capable layer 3 stack. A solar powered routers will continue to only be layer 2 and that is ok. With this possible world view, I think improving the layer 2 services is really important, this include next-hop routing. There is also different use cases, a burning man event is very different from a city wide mesh with a few reliable hilltop routers. For the two problems you pose:

• I have often seen asymmetric links myself. I would have to put some brain power on this.
• As for falling back to flood routing, I would rather it be turned off or have a bit to switch that off. In my case, I would like to use next-hop routing to discover and exclusively use reliable paths. The flood fallback would sort of mess that up. Of course, layer 3 would eventually see things are not working and try flood or path discovery again.

[b8b8]

In the interim, since you don't want to fall back to flood routing, is it feasible for you to setup your own routers on a seperate frequency to guarantee only the path you want is used?

[Ylianst]

The amazing part of MeshTastic is the public mesh. I want to be able to have others use my routers and use others. Yes, it's possible, but, I rather stick with the community.