The publisher side filtering implementation is in the m_trie (used by
XPUB). I missed it the last time I was looking for it. It uses the trie
data structure to link subscriptions to pipes. You can use XPUB in place
of PUB. You will just need to throw away the recv's.
Joshua
On 3/13/2012 7:22 PM, Steve wrote:
I setup the "C++ weather update" client / server (from the ZeroMQ
guide) on two machines. I have the server on one machine and the
client on another. I hard coded the server to only publish zip code
"11111". The client subscribes to "22222". Although my client code
doesn't 'see' the messages (as expected), I see the "11111" messages
traveling to the client machine using WireShark so ZeroMQ must be
filtering them out on the client side (not the publishing side).
I was interested in the built-in PubSub as a possible foundation to
build a game server with 100's or 1000's of clients (players).
However, if each published messages has to go to each client (even if
they don't need it) I think it will overwhelm the network (or the
clients machine). This would be especially true for slower clients
like mobile devices. The v3.1 XPUB XSUB only solves part of the
problem if you are using many layers of publishers and subscribers.
However, I haven't found a pattern or solution where someone has dealt
with the "last published leg" where the messages are sent to the
client end points. Maybe the "Dealer" / "Router" would work but it
sounded like there might be some problems if the clients disconnected.
Any other thoughts are appreciated.
Thanks,
Steve
On Tue, Mar 13, 2012 at 12:39 PM, Calvin de Vries
<devries.cal...@gmail.com <mailto:devries.cal...@gmail.com>> wrote:
I'm not sure this is correct, Joshua. PUB filters the messages in
3.1, while you can use XPUB in order to do more advanced
subscription management, it is not a requirement to have publisher
side filtering.
In Steve's example, Subscriber A would not receive every message,
only messages matching its filter.
On Mon, Mar 12, 2012 at 7:43 PM, Joshua Foster <jhaw...@gmail.com
<mailto:jhaw...@gmail.com>> wrote:
3.1 works the same way as 2.1 in your example. The changes in
3.1 is that the subscription is forwarded to the PUB socket.
This allows you to create a publisher device. It would sit
between the parent publisher and the subscriber. The XPUB
keeps track of the subscriptions and allows them to apply to
the XSUB socket. This effectively filters out any messages
that do not match a subscription. In your example, you are
matching against "a" and "" so all messages would be passed
through.
You can of course use a ROUTER socket and manage the
subscriptions yourself in the application (with DEALER). The
main downside is that you won't be able to detect client
disconnections. You may also want to consider creating an
alternative PUB socket implementation in ZeroMQ.
Joshua
On 3/12/2012 6:48 PM, Steve wrote:
I have a high level question about how a v3.1 publisher
handles sending updates to subscribers. I understand that
v3.1 can push the subscription filtering further towards the
publisher but to what degree I'm unclear on.
Here is a very simple usage example:
1) Publisher has a list of topics that are randomly updated
10 times a second. There are a total of 26 topics and each
is a single lowercase alpha character representing the
English alphabet (a - z).
2) Subscriber 'A' subscribes to just a topic matching "a".
3) Subscriber 'B' subscribes to all topics ("").
In version 2.1, I believe Subscriber 'A' would receive all
the messages and that the zeromq client library would filter
them so the client would only see updates on 'a'. In version
3.1, is it possible to filter the messages at the publisher
so that Subscriber 'A' only receives updates on topic 'a' (no
filtering done on the client) and that Subscriber 'B'
receives all updates on all topics (a-z)?
Thanks,
Steve
_______________________________________________
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org <mailto:zeromq-dev@lists.zeromq.org>
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
_______________________________________________
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org <mailto:zeromq-dev@lists.zeromq.org>
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
_______________________________________________
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org <mailto:zeromq-dev@lists.zeromq.org>
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
_______________________________________________
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
_______________________________________________
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
