[Feature Request]: Client_Base Improvement

[MitchBaker]

Platform

Cross-Platform

Description

Current behavior of CLIENT_BASE is a wonderful improvement - but there could be one small change that I think would make it better and improve it's utility bridging between CLIENT and ROUTER.

Current behavior is only rebroadcasting all message if the sender or recipient is on the favorite node list. This is likely to leave some messages undelivered from public / private channels where the CLIENT_BASE device hears the message - but the user node does not. While the impact of this is minimal, and I understand why this decision was made - one small change could improve this even more.

From what I understand devices sending telemetry automatically adjusts frequency based on Chanel utilization and air utilization. This makes sense as if there is a lot of traffic on the frequency, you don't want to unnecessarily add unimportant traffic as well.

If we turn this around for CLIENT_BASE and act as a ROUTER or ROUTER_LATE if the frequency is below a threshold, but defaulting to current CLIENT_BASE behavior for Favorite nodes only if above the threshold we can improve message receiving and reliability of public messaging while not impacting the local mesh adversely.

This increases the utility of CLIENT_BASE mode by being a larger contributer to the local mesh with all messages when the mesh can benefit, but not negatively impacting the mesh during high traffic times / or when the local mesh naturally can support the messaging.

Flow would look like this -

Message received >
---- Is message from or to favorite node? >
---------- Yes > Rebroadcast as CLIENT_BASE Priority.
---------- No >
----------------- Frequency utilization below threshold? >
------------------------- Yes > Rebroadcast as CLIENT_BASE priority
------------------------- No > Rebroadcast as CLIENT priority if necessary.

If we can automatically limit non-message transmissions during high utilization, we can also be looser with a late re-broadcast of actual messages during low utilization.

[korbinianbauer]

Just because there's not a lot of traffic doesn't mean a badly placed ROUTER won't negatively affect the routing. It can still stop near clients from rebroadcasting, despite the router not reaching the recipient.

Acting like ROUTER_LATE if there's little traffic, yeah, maybe

[shalberd]

Acting like ROUTER_LATE if there's little traffic, yeah, maybe

agreed, ROUTER_LATE like acting would be preferred, but then again the issue with not having CLIENT_BASE was no way to override / prioritize messages via rooftop nodes for a client mute mobile node or window node at ground level.

On second thought, that is exactly what ROUTER_LATE does, deferred transmit in all cases, so yeah, either

• ROUTER with favoriting of nodes (as is)
• ROUTER_LATE behavior

for CLIENT_BASE role.

[shalberd]

Just because there's not a lot of traffic doesn't mean a badly placed ROUTER won't negatively affect the routing

agreed, ROUTER-like behavior will always forward the package first, before all other Clients, in the early rebroadcast window. https://meshtastic.org/blog/demystifying-router-late/
See also my discussion with Meshtastic maintainer below that article, which was very interesting and productive.

[Ryu945]

This doesn't do it the same way but this idea is similiar to it. I just happen to use the name Client_Base for this new type of node. It essentially lets users give a slight rebroadcast priority to well placed nodes by setting them as well placed nodes.

#8117