Currently we still send too many updates in a fully connected mesh. The
provider currently knows not to resend an update to the originating server,
and also not to resend an update to the server that just relayed the update to
it. We should also filter out updates that we know another server is likely to
receive from an alternate path.
E.g. in a 4-way mesh:
1 - 2
| X |
3 - 4
When server 1 receives an update from a client, it will propagate it to each
of 2, 3, and 4. These servers will also attempt to propagate it to each other:
2 to 3,4; 3 to 2,4; and 4 to 2,3. If these further updates are not quite
simultaneous, it is possible that one or two redundant updates will be pruned
out given the existing code. But that's just based on luck and variations in
server and network load.
Once any node has received any updates from a given sid, it should be able to
remember which neighbors have sent it identical updates, and filter them out
from further propagation attempts.
Of course, this may turn out to be a bad idea; if one of the nodes loses one
connection, it might stop receiving updates altogether even though other
servers could forward to it. I guess we can't protect against this case
without at least some redundant messages still being generated.
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/