Replies: 2 comments 9 replies
-
|
Neighbor Information is massive, relatively speaking :) We had to turn default neighbour info sharing way down because it severely loaded the mesh. For this idea to work well, neighbour info would need to be shared very frequently. It seems there just isn't enough bandwidth for this kind of idea. |
Beta Was this translation helpful? Give feedback.
9 replies
-
|
A better system to improve network reliability was discovered so closing this. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Platform
Cross-Platform
Description
Instead of having Client nodes always silence rebroadcasting if someone else does it first, what if we made this decision based on the actual network configuration?
A node will keep a list of all their neighbors (Nodes they can directly communicate with). A node will share its neighbors with its neighbors. A node will save not only a list of its own neighbors but the neighbors around it neighbors. If a message is broadcasted while this neighbor data is empty, Meshtastic would work the same way it does now. If a message is broadcasted from Node A and Node B rebroadcast it first (Based on SNR); Node C which also heard the message will check to see if it knows any nodes that Node B doesn't know. If it does then it will broadcast anyway and not be silenced by Node B. If it doesn't then it will not rebroadcast.
SNR based timings are still used but whether a Node is silenced can be overrided based on who Node C knows and who Node B doesn't know.
A node will probably have to be on for so long before it starts using the override based on neighbor information.
Beta Was this translation helpful? Give feedback.
All reactions