[Feature Request]: Retransmit messages received in public channel to favorite nodes from CLIENT_BASE node

[udenfox]

Platform

Cross-Platform

Description

I'm running my solar rooftop node and my apartment node on the latest beta (2.7.15). Rooftop node set up as "CLIENT_BASE", and my apartment node added as favorite on it.

It works perfectly fine and exactly as designed for private messages - all messages FROM and TO my apartment node get retransmits by my rooftop node.

But I have noticed it does not work with public channels (for example LongFast).

When I connect to my rooftop node and compare LongFast channels chat from there AND from my apartment node - some messages I can see on my solar node just simply missing on my apartment one.

It's not hop-related too: some missing messages was recieved directly by my solar node and still was not retransmitted.

I understand that I can fix it by putting solar node into ROUTER_LATE, but want to avoid it as much as possible.

[b8b8]

Public channel messages arent "directed" anywhere. If you restransmit them to your "favorite" node it would be the exact same as just setting it to router/router_late (same impact on the wider mesh).

[udenfox]

Not totally the same. router_late making messing noticeably slower for both public and DM.

Some traceroutes through router_late take up to 110 seconds, while client_base doing it much faster, usually within 30 seconds

[github-actions[bot]]

This issue has not had any comment or update in the last month. If it is still relevant, please post update comments. If no comments are made, this issue will be closed automagically in 7 days.

[hchak]

I support this with the caveat that client_base rebroadcast window changes to router_ late style, going after all other routers and clients - but always rebroadcasting at the end of the time window.

[Hamberthm]

Hi, I´ve loosing messages on LongFast on my indoor node because of this problem.

As I proposed in this idea post, we could:

• Rebroadcast ALL messages at least ONE MORE TIME. For the messages the algorithm decided should not be rebroadcasted, do it one more time after setting the remaining hops to 0, ensuring no further propagation but reach to the indoor node.
• A mechanism similar to S&F could be implemented, where the indoor node could ask the roof node for missing LongFast and the like messages.

[b8b8]

Hi, I´ve loosing messages on LongFast on my indoor node because of this problem.

As I proposed in this idea post, we could:

* Rebroadcast ALL messages at least ONE MORE TIME. For the messages the algorithm decided should not be rebroadcasted, do it one more time after setting the remaining hops to 0, ensuring no further propagation but reach to the indoor node.

* A mechanism similar to S&F could be implemented, where the indoor node could ask the roof node for missing LongFast and the like messages.

That's basically just router mode then. Client_Base is designed to solve MOST of the issues of indoor nodes, but focusing on incoming and outgoing DMs, and outgoing channel messages. But if you rebroadcast ALL messages regardless, you just recreated a ROUTER which already exists as a role and can be bad for the mesh.

[Hamberthm]

Hi, I´ve loosing messages on LongFast on my indoor node because of this problem.
As I proposed in this idea post, we could:

* Rebroadcast ALL messages at least ONE MORE TIME. For the messages the algorithm decided should not be rebroadcasted, do it one more time after setting the remaining hops to 0, ensuring no further propagation but reach to the indoor node.

* A mechanism similar to S&F could be implemented, where the indoor node could ask the roof node for missing LongFast and the like messages.

That's basically just router mode then. Client_Base is designed to solve MOST of the issues of indoor nodes, but focusing on incoming and outgoing DMs, and outgoing channel messages. But if you rebroadcast ALL messages regardless, you just recreated a ROUTER which already exists as a role and can be bad for the mesh.

Maybe you didn't understand my proposal completely. I said retransmit all packets that should be retransmitted, just like CLIENT mode, and the ones that client mode refuses to retransmit, do so BUT setting the hop count to 0. This is not like ROUTER works, AFAIK.

[fgimenezm]

Maybe this is an impossible idea, I don't know if it's technically possible, but here it goes anyway...

what if CLIENT_BASE would do something like this for non DMs messages:

• Apply the normal CLIENT logic first (eg: retransmit if the current hop and "no one else broadcasted" rules apply)
• If the decision of applying that logic is "don't retransmit" then instead of silently moving on it could retransmit at a later time, just like ROUTER_LATE, but not only setting hop count to 0 but also using a lower transmission power (this last TX power tweak I don't know if it's technically possible on a per-message basis which would render my ideal useless if it's not).

That way it will give the closer indoor nodes a better chance of getting the message without adding unnecessary retransmission noise to the rest of the mesh.

Just my 2 cents.