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/