The existing options allow only for publishing the current Peer's info on a fixed interval, and once automatically at start up. However, when a new peer joins which is also participating in the PubSub Peer Discovery process, it has to wait until the next interval to receive notification of existing peers. This creates an unnecessary trade-off between a low broadcast interval (causing lots of chattiness) or a long delay until peer discovery.
The PubSub interface provides the ability to see when new peers have subscribed to various topics. This patch adds a very small amount of optional logic to broadcast our peer info reactively when we see new peers on the topic. The default configuration is to disable this functionality unless the user specifically opts in.
Also, if there were a large number of peers participating in the PubSub Peer Discovery process, having them all broadcast their peer details in synchronization would create somewhat of a 'thundering herd' problem. Therefore, I have included a configurable randomized delay for this reactive broadcast. By default it is a fraction of the broadcast 'interval', but can be configured as desired.
The existing options allow only for publishing the current Peer's info on a fixed interval, and once automatically at start up. However, when a new peer joins which is also participating in the PubSub Peer Discovery process, it has to wait until the next interval to receive notification of existing peers. This creates an unnecessary trade-off between a low broadcast interval (causing lots of chattiness) or a long delay until peer discovery.
The PubSub interface provides the ability to see when new peers have subscribed to various topics. This patch adds a very small amount of optional logic to broadcast our peer info reactively when we see new peers on the topic. The default configuration is to disable this functionality unless the user specifically opts in.
Also, if there were a large number of peers participating in the PubSub Peer Discovery process, having them all broadcast their peer details in synchronization would create somewhat of a 'thundering herd' problem. Therefore, I have included a configurable randomized delay for this reactive broadcast. By default it is a fraction of the broadcast 'interval', but can be configured as desired.