[zeromq-dev] XSUB/XPUB proper usage

[Kenneth Adam Miller]

This triggers it:

//test.cpp
#include <zmq.hpp>

int main(void) {
  zmq::context_t ctxt{1};
  zmq::socket_t * xpub = new zmq::socket_t{ctxt, ZMQ_XPUB};
  xpub->bind("inproc://pub");
  zmq::socket_t * xsub = new zmq::socket_t{ctxt, ZMQ_XSUB};
  xsub->bind("inproc://sub");
  zmq::proxy(xsub, xpub, NULL);
}

compiled with:

g++ -std=c++11 test.cpp -lzmq -o test

On Tue, Dec 30, 2014 at 10:42 AM, Kenneth Adam Miller <
kennethadammiller at gmail.com> wrote:

> Didn't think you were, was just explaining my reasoning. Thank you!
>
> I'll do my best to create a workable, minimal reproduction of the issue.
>
> In the meantime on my end, I just put it in a thread that sits in a loop
> reading from XSUB and sending that to XPUB
>
> On Tue, Dec 30, 2014 at 3:36 AM, Pieter Hintjens <ph at imatix.com> wrote:
>
>> I'm not challenging your issue, just looking at the code, which
>> doesn't check the socket types. Any chance you can open things up to
>> see where the exception is coming from? Or, replace either of the
>> socket types with another and see if that changes things. I'd
>> investigate, except I'm deep into other stuff.
>>
>> On Tue, Dec 30, 2014 at 7:08 AM, Kenneth Adam Miller
>> <kennethadammiller at gmail.com> wrote:
>> > Well, it doesn't throw the exception when I comment the proxy line out.
>> And
>> > it does when I uncomment it. That one change back to back is
>> differentiating
>> > it. I have no idea why it's throwing, that's literally the code. It
>> runs in
>> > a thread created in the constructor of a singleton object.
>> >
>> > On Tue, Dec 30, 2014 at 12:24 AM, Pieter Hintjens <ph at imatix.com>
>> wrote:
>> >>
>> >> There is nothing in the proxy code that would reject a XPUB or XSUB
>> >> socket.
>> >>
>> >> On Mon, Dec 29, 2014 at 11:50 PM, Kenneth Adam Miller
>> >> <kennethadammiller at gmail.com> wrote:
>> >> >
>> >> >
>> >> > On Mon, Dec 29, 2014 at 3:23 PM, Pieter Hintjens <ph at imatix.com>
>> wrote:
>> >> >>
>> >> >> Either XSUB or SUB can connect to XPUB. With XSUB you have to send
>> the
>> >> >> subscribe / unsubscribe messages yourself. With SUB they're sent by
>> >> >> the socket. In either case the XPUB will detect a dead (X)SUB peer
>> and
>> >> >> generate ubsub messages up to the API.
>> >> >
>> >> >
>> >> > Thank you!
>> >> >
>> >> > Now I'm having issues with socket operation on non-socket
>> exceptions...
>> >> >   _xpub = new zmq::socket_t(_context, ZMQ_XPUB);
>> >> >   _xpub->bind("inproc://killpub");
>> >> >   _xsub = new zmq::socket_t(_context, ZMQ_XSUB);
>> >> >   _xsub->bind("inproc://killsub");
>> >> >   zmq::proxy(_xsub, _xpub, NULL);  //throws here
>> >> >>
>> >> >>
>> >> >> On Mon, Dec 29, 2014 at 5:08 PM, Kenneth Adam Miller
>> >> >> <kennethadammiller at gmail.com> wrote:
>> >> >> >
>> >> >> > On Mon, Dec 29, 2014 at 11:03 AM, Pieter Hintjens <ph at imatix.com>
>> >> >> > wrote:
>> >> >> >>
>> >> >> >> On Mon, Dec 29, 2014 at 4:51 PM, Kenneth Adam Miller
>> >> >> >> <kennethadammiller at gmail.com> wrote:
>> >> >> >>
>> >> >> >> > Now my questions: for xpub and xsub do you do the following:
>> >> >> >> >   pub->setsockopt(ZMQ_SUBSCRIBE, "", 0);
>> >> >> >>
>> >> >> >> No, this works only on SUB sockets.
>> >> >> >>
>> >> >> > I meant sub->setsockopt... but now that makes me think- don't I
>> use
>> >> >> > ZMQ_SUB
>> >> >> > to connect to ZMQ_XPUB?
>> >> >> >
>> >> >> >>
>> >> >> >> > at all? Or does the following handle it completely:
>> >> >> >> >   char *s = "xsubscriptionprefix";
>> >> >> >> >   s[0]='\x01';
>> >> >> >> >   sub->send(s);
>> >> >> >>
>> >> >> >> Yes.
>> >> >> >>
>> >> >> >> > Also is there a need for unsubscription upon closure of sub?
>> >> >> >> > char *s="\x00";
>> >> >> >> > sub->send(s);
>> >> >> >>
>> >> >> >> Not needed at the SUB side at all; it's handled by the PUB
>> socket.
>> >> >> >> (I
>> >> >> >> think, from memory.)
>> >> >> >>
>> >> >> >> -Pieter
>> >> >> >> _______________________________________________
>> >> >> >> zeromq-dev mailing list
>> >> >> >> zeromq-dev at lists.zeromq.org
>> >> >> >> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> > _______________________________________________
>> >> >> > zeromq-dev mailing list
>> >> >> > zeromq-dev at lists.zeromq.org
>> >> >> > http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>> >> >> >
>> >> >> _______________________________________________
>> >> >> zeromq-dev mailing list
>> >> >> zeromq-dev at lists.zeromq.org
>> >> >> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>> >> >
>> >> >
>> >> >
>> >> > _______________________________________________
>> >> > zeromq-dev mailing list
>> >> > zeromq-dev at lists.zeromq.org
>> >> > http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>> >> >
>> >> _______________________________________________
>> >> zeromq-dev mailing list
>> >> zeromq-dev at lists.zeromq.org
>> >> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>> >
>> >
>> >
>> > _______________________________________________
>> > zeromq-dev mailing list
>> > zeromq-dev at lists.zeromq.org
>> > http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>> >
>> _______________________________________________
>> zeromq-dev mailing list
>> zeromq-dev at lists.zeromq.org
>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20141230/31642bc9/attachment.htm>