[zeromq-dev] XSUB/XPUB proper usage

[Kenneth Adam Miller]

Need to de-reference the pointers; the prototype given for the zmq wrapper
is void * for all parameters... so it doesn't differentiate at compile time.

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

> 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);
>
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/21e25c43/attachment.htm>