Sounds reasonable ... And smell like routing protocols at least a bit as BGP tables are getting larger and need memory at the router. I rather compare it to switches where TCAMs are expensive and small, At Least today. Thanks for the clarification, seems network principles can arrive in applications. -- Holger Winkelmann Travelping GmbH +49-171-5594745 ### Sent from a mobile device. Sorry for brevity and typos... ### On 19.01.2013, at 17:17, Martin Sustrik <sustrik@xxxxxxxxxx> wrote: > On 18/01/13 16:37, Holger Winkelmann [TP] wrote: > >> Sounds OK. But whats the difference of the Subscriber Filter algorithm >> at subscriber compared to the router? I suspect the Router need to combine >> the Filter of all Subscribers which have messages passing the router? And >> this >> will either lead to huge tables or to a algorithm which may is not perfect, >> right? > > Yes. Exactly. Assuming that memory on the router is limited, we have to do > imperfect filtering. (E.g. creating a hash, where hash collisions result in > non-matching messages passing the filter.) AFAIK that's exactly how IP > multicast group filtering is implemented in most network switches and NICs. > >> My question would be: has this any consequences to the behavior or is >> it "just" adding some costs for the transport and bandwidth? > > The point of the architecture is that there's no impact on behaviour. Perfect > message filtering is done on the terminal subscriber, so the end user always > gets perfectly filtered messages. Forwarding subscriptions to intermediate > nodes is strictly an optimisation and has effect only on bandwidth usage, > never on semantics of the application. > > Martin