-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/05/14 07:58, Martin Sustrik wrote: > The more I think of it the more this looks like the best solution > so far. The setting would have to be on both subscriber (send at > most 32 subscriptions upstream, if there are more of them, stop > caring) and publisher side (consider subsriber that issues more > than 32 subscriptions ill-behaved and disconnect it). > > It will also solve the problem of subscription resending: If there > are at most 32 subscriptions per consumer, it's not likely they > will overload the network. (Maybe we should also put some limit on > the subscription length though.) One more though on the topic: One thing I was concerned about was aggregation of small subscriptions from individual end subscribers into large subscription sets in the topologies with large number of subscribers. So, each end subscriber may have emmitted only a single subscription, however, few levels upstream in the distribution tree way may be working with sets of millions of subscriptions. The strategy of limiting the number of subscriptions to 32 per subscriber helps to solve that in a neat way: If aggregated sum of subsccriptions from a distribution sub-tree exceeds 32, the publisher publishing to that subtree will switch into "deliver everything" mode. Martin -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTZd3EAAoJENTpVjxCNN9YM3QH/0fYI1wUs+teP7TYjk0+CYWk lD2yl5J8VHXjMkZZgFJ7cily6kGhzjVxCIqlX8j/tNHvrSD41xRpcKKswnUAjGzl yXxw3FPXeTfQUt50Vs764/0Iac8mwvzV8lUAggdOTZjujJk5vmrG43HLRySFxcn1 h7uUSrQamgJGpENDC8alWzfGyerf53Q6HO33XQBfYCVot9FXevVY0BvzT8A92Hx/ sm3aboQPmH8tJOz9prI8tLCx/D88Dq51yy+CmAMC38IFLysf35SShIjKgau8J6Zp 7pt8BtUvXTGuVdiN6iSPvhlJD0N3XIzpIrug7DEKYZ3BqnShrYYY83cD5WqycV0= =73JW -----END PGP SIGNATURE-----