On Wed, Mar 14, 2012 at 1:31 AM, Joshua Foster jhaw...@gmail.com wrote:
PUB functions the same in 3.1 as 2.1, but XPUB actually does publisher
side filtering. (if I read the code correctly)
Joshua
Don't think you did Joshua - they both use the same distribution code
(dist/send to
Steve I just checked via Wireshark. It is doing PUB side filtering. Are you
sure that you are testing this with zmq 3.1? I setup a simple PUB/SUB in
zeromq.node https://github.com/shripadk/zeromq.node fork. Here is my test
code:
// subscriber:
var zmq = require('zmq-3.0');
var sub =
Shripad,
It sounded like Pub/Sub was essentially the same on 2.1 vs 3.1 other than
the XPUB / XSUB. So, I just took the example from the 0MQ guide which is
v2.1 I believe. I will try your test on 3.1 and verify.
Thanks for looking into this!
Steve
On Wed, Mar 14, 2012 at 3:07 AM, Shripad K
Shripad,
You are correct. 3.1 *does* filter the messages on the publisher side
whereas 2.1 does not. I verified this with WireShark as well.
Thanks again,
Steve
On Wed, Mar 14, 2012 at 1:51 PM, Steve steve.frien...@gmail.com wrote:
Shripad,
It sounded like Pub/Sub was essentially the
Yes, I was wrong. Sorry for the incorrect info.
Joshua
On 3/14/2012 5:30 PM, Steve wrote:
Shripad,
You are correct. 3.1 *does* filter the messages on the publisher side
whereas 2.1 does not. I verified this with WireShark as well.
Thanks again,
Steve
On Wed, Mar 14, 2012 at 1:51 PM,
No problem :) Glad I was of help :)
On Thu, Mar 15, 2012 at 6:33 AM, Joshua Foster jhaw...@gmail.com wrote:
Yes, I was wrong. Sorry for the incorrect info.
Joshua
On 3/14/2012 5:30 PM, Steve wrote:
Shripad,
You are correct. 3.1 *does* filter the messages on the publisher side
Joshua, thanks, that clears it up.
The v3.1 XPUB / XSUB keeps the system really scalable and efficient if you
have cascading publishers / subscribers. However, the last leg to the
subscriber is still going to have 'unwanted' messages going to certain
subscribers (Subscriber 'A' in my example).
On Tue, Mar 13, 2012 at 1:06 PM, Steve steve.frien...@gmail.com wrote:
Joshua, thanks, that clears it up.
The v3.1 XPUB / XSUB keeps the system really scalable and efficient if you
have cascading publishers / subscribers. However, the last leg to the
subscriber is still going to have
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
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 1. The client
subscribes to 2. Although my client code doesn't 'see' the messages
(as
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
PUB functions the same in 3.1 as 2.1, but XPUB actually does publisher
side filtering. (if I read the code correctly)
Joshua
On 3/13/2012 1:39 PM, Calvin de Vries 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
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
13 matches
Mail list logo
