Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Feature Request]: Routers behave as clients when they see another router, so clients will not see both and retransmit. #4590

Closed
quimnut opened this issue Aug 30, 2024 · 8 comments
Labels
enhancement New feature or request

Comments

@quimnut
Copy link
Contributor

quimnut commented Aug 30, 2024

Platform

other

Description

My understanding is that a client will not flood route if it sees a retransmit.

In the scenario that an actor operates 2 routers, a client that hears both will not flood route.

This means a router will break any client mutes behind a client and as such breaks a mesh, it would require router mode for any intermediate hop like a roof top.

I feel an option would be a router should act as a client if it sees another router in hop 0.

Happy to be wrong, thanks for all the love. Meshtastic is a great community.

@quimnut quimnut added the enhancement New feature or request label Aug 30, 2024
@GUVWAF
Copy link
Member

GUVWAF commented Aug 30, 2024

Unfortunately this is an edge case, which indeed may happen, but it doesn't matter that there are two routers, it can happen with one router and even with clients only. Take this scenario for example (taken from #2856):
image

Here node 1 is rebroadcasting the packet from 0, because it has the worst SNR. Then 2 won't rebroadcast, because it hears 1 doing so already. However, in this case it would have been better if 2 rebroadcasted it, such that it reaches 3.
In this case if 2 was a ROUTER, it would be solved.

In your case it's like your CLIENT_MUTE is node 3, your CLIENT node is 2 and node 1 is a ROUTER. Node 1 will always rebroadcast first, causing the CLIENT not to. It doesn't matter if the original transmitter is a ROUTER or not.

@quimnut
Copy link
Contributor Author

quimnut commented Aug 30, 2024

Thank you @GUVWAF that's a very clear summary.

@quimnut
Copy link
Contributor Author

quimnut commented Aug 30, 2024

Can we expand on why this is an edge case?

@GUVWAF
Copy link
Member

GUVWAF commented Aug 30, 2024

Maybe not really an edge case, but something that can happen in a specific scenario like this. In a slightly different scenario, where there would be another node that can hear 0 but not 1, it would also rebroadcast and 3 could receive that.

There's a trade-off between reliability and redundancy here. If every node would rebroadcast, this scenario would still work, as long as it doesn't create collisions.

@quimnut
Copy link
Contributor Author

quimnut commented Aug 30, 2024

How specific is a case of 2 routers in earshot?

@GUVWAF
Copy link
Member

GUVWAF commented Aug 30, 2024

But how would that create this issue in scenarios where it would otherwise still work?
Anyone rebroadcasting earlier than you causes you to not rebroadcast. So, it might get worse if someone is setting its node as router, but I don't see how 2 routers would make it happen in more scenarios than 1 router.

@fifieldt
Copy link
Contributor

@GUVWAF
Copy link
Member

GUVWAF commented Aug 31, 2024

The hidden node problem is indeed what causes collisions. This is more similar to the "Exposed node problem", where you prevent from sending when someone else did, while your neighbor didn't receive the other's transmission.

@thebentern thebentern closed this as not planned Won't fix, can't repro, duplicate, stale Aug 31, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

4 participants