[nanomsg] Re: publisher side filtering

  • From: Martin Sustrik <sustrik@xxxxxxxxxx>
  • To: nanomsg@xxxxxxxxxxxxx
  • Date: Sun, 04 May 2014 14:34:55 +0200

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Btw,

I've added dummy publish/subscribe RFC into rfc subdirectory so that
we have a sandbox to play in.

Martin

On 04/05/14 08:27, Martin Sustrik wrote:
> 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/

iQEcBAEBAgAGBQJTZjPpAAoJENTpVjxCNN9Y31oIAKg0v70VghR0bEjhDTvNn0DS
7+SPFZO/xtxN7KIv7UKpcNqtD0elw2MH1vIQ7XuJ7kzgx80jwhn1/S4hWgEUGWzS
QDuSzsnUZ+n/GVxmI9VrIoS0T5cks3q7Vi/VqcDnF2X+7JLHsGZIPyjqu+ZayoWG
GjxnGvfyCsIqHixUoL53xVAABzAzlD/8Na4FXI/KMVLGdZwmuDAcImXVOPtenzmg
wLbKArHm6aNy5bgtaTnnJBemRWmEYesbQji4VI3vYH81lJFwF9NuDJ3VGeleSsXm
KiFjJyJuZOsR3+J2GeWOTKU0ir6W0oqASYpb8Eh4S8FfQVzNjRrlzuwJUHEcWpM=
=jJx1
-----END PGP SIGNATURE-----

Other related posts: