[zeromq-dev] Need for Late join and End of source detection

Rohan Bedarkar r_bedarkar at yahoo.com
Tue Oct 2 22:06:20 CEST 2012

Unfortunately, no luck with XPUB. Just a reminder I am using epgm.

Here's the snippet on the publisher side. 

    zmq::context_t context (1);
    zmq::socket_t publisher(context, ZMQ_XPUB);
    char buff[32];

    int rc = publisher.recv(buff, sizeof (buff), 0);
    std::cout << "Subscription received = " << buff << std::endl;

Despite trying to subscribe from the other side the code keeps blocking on publisher.recv(). 

By the way if I remove the last 2 lines of code everything works fine. Am I missing something? Has XPUB\XSUB been tested over PGM? 


Rohan Bedarkar
MS, Computer Science 

University of Chicago
rohanb at cs.uchicago.edu


 From: Pieter Hintjens <ph at imatix.com>
To: Rohan Bedarkar <r_bedarkar at yahoo.com>; ZeroMQ development list <zeromq-dev at lists.zeromq.org> 
Sent: Monday, October 1, 2012 5:10 PM
Subject: Re: [zeromq-dev] Need for Late join and End of source detection
On Mon, Oct 1, 2012 at 11:44 PM, Rohan Bedarkar <r_bedarkar at yahoo.com> wrote:

> XPUB \ XSUB looks good for me. I can certainly use an XPUB to detect a new
> incoming subscription. Quick question though... Must XPUB\XSUB be used at
> intermediate layer? Can final endpoints be XPUB\XSUB? I don't want to add a
> proxy layer in the middle.

Sure, end points can use XPUB, though an inprocess proxy doesn't add
much overhead and can abstract it nicely IMO.

> Also not sure how the XSUB will detect if the XPUB on the other went down?
> (I am assuming here that XPUB \ XSUB can be used as endpoints).

You'd want to send heartbeats at the publisher side. Perhaps with a
thin API at both ends.

zeromq-dev mailing list
zeromq-dev at lists.zeromq.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20121002/f0873f07/attachment.htm>

More information about the zeromq-dev mailing list