Currently the routing algorithm requires everyone to keep a full routing table on how to send data for each topic.
The routing algorithm can under some scenarios lead to same message being relayed unnecessary many times
The current algorithm is quite CPU intensive because it uses Djikstra to find routes. Works well < 1000 peers, Does not work well when peers > 1m
There are no ways to nicely adapt to bandwidth limits
TODO:
Lazy routing
When you publish data on a specific topic you will initially send data in a flood sub manner. Later on, when ACK messages are propagated in return you will learn what the fastest way is to reach peers, and from that build a table to use for optimaly route packages.
This will simplify the protocol and make it more performant.
This will most likely lead to breaking changes in the pubsub protcol
Lazy get subscribers
Only poll a updated list of all subscribers when needed instead of a push bashed approach which will not scale well when there are thousands of subscribers
Rework error and warning messages: Only show errors and warnings when absolutely necessary.
Problem:
TODO:
Lazy routing
When you publish data on a specific topic you will initially send data in a flood sub manner. Later on, when ACK messages are propagated in return you will learn what the fastest way is to reach peers, and from that build a table to use for optimaly route packages.
This will simplify the protocol and make it more performant.
This will most likely lead to breaking changes in the pubsub protcol