Revisiting CLIENT_ROUTER in a way that makes sense

[tedwardd]

CLIENT_ROUTER was initially confusing and was removed in favor of separate CLIENT and ROUTER roles with the generally accepted wisdom to "Always select CLIENT unless you are in a highly advatageous location such as a mountain top". But I would argue that there is an in-between scenario where ROUTER could be useful in a more localized context.

Imagine a scenario where you are in an home or office building where your client nodes are able to reach the wider mesh via a neighboring client in another building nearby, but their range is extremely limited for the same reasons that your range is limited (physics). Placing a client outside of your building, say, on the roof provides much more advantageous position from which to access to the wider mesh. However, because the current routing algorithm for clients is based on SNR and the random wait from the contention window, it's highly likely that the poorly placed client node in the neighboring building will relay our message instead of our well placed node on the roof. It would be much better if there were some way to set up a client such that if it were to recieve a packet from a predefined set of clients, it would behave as a ROUTER and immediately relay packets that it hears from these clients.

There are two possible approaches to implementing this:

1. Pre-defined lists of clients within the relay nodes configuration (managed)
2. A "preferred router" setting on the client (ad-hoc)

Of the two options, "managed" requires less changes to the existing meshtastic system. The administrator of the relay node need only configure the IDs of it's clients in order to recognize the packets in which is should act as the router.

The second option is more flexible, allowing clients to decide what node they want to act as their first hop, but requires changing the packet encoding to extend the length of the header. The additional header space would be used to encode the ID of the client's "preferred router". Upon receiving a packet, any node on the network can read this information and decide whether to relay the packet like any other CLIENT on the network or to relay the packet immeditaely, like ROUTER.

Doing this would allow for well placed nodes, even in areas with very dense meshtastic presence, to act as routers within a limited scope without impacting the performance of the larger network as a similarly placed ROUTER under the current definition would.

[garthvh]

There is not a need for more routers, there should be less. A router should be on a mountain, or the node should be a client.

[tedwardd]

While I agree that, in its current incarnation, more clients and fewer routers make more sense. Providing the ability for a node in a poorly covered area to specify a particular node through which the first hop should be routed makes a lot of sense in many cases including the example I provided in the original post.

I say this because I am personally in such a situation. When I am in the basement of my house, my client node in my pocket can reach a few houses down to another client node which dutifully tries to relay my packets, however, if I directly sent from the relay node on the pole 40' above my roof line, I'm able to get to far more distant nodes and to nodes within normal range with far fewer hops, or in some cases, directly.

Having the ability to set my client node up in a way that it will always send messages through my relay on the roof when available makes much more sense than using best effort routing mechanisms to hop through poorly positioned clients.

[GUVWAF]

The actual problem here is that the poorly positioned CLIENT in the building nearby should be CLIENT_MUTE.

[tedwardd]

I agree, but without knowing how to contact the owner of the offending node (or block it from relaying messages) I have no recourse in this matter. There should be a way to compensate for poor node behavior. Perhaps that is the takeaway from this. Setting up base stations in a way that routes packets for specific clients may be a dud but if communication can be impacted by a single poorly behaving node there should be mechanisms by which clients can handle that and work around them.