It is not reliable (and currently doesn't support PGM). It is pretty new and not yet documented, you can take a look at the test:
https://github.com/zeromq/libzmq/blob/master/tests/test_radio_dish.cpp Few differences from pubsub: * Exact matching (vs prefix matching of pubsub) * Group (Topic) is null terminated string * Group is currently limited to 16 chars (including terminating null), should be extended in the future * To join/leave a group you call zmq_join/zmq_leave (vs zmq_setsockopt of pubsub) * To set the group of a message you need to set msg group property using zmq_msg_set_group * It doesn't support multipart (the group is part of the message) Hopefully will document it soon. Doron On Tue, Apr 26, 2016 at 5:52 PM, Utsav Drolia <[email protected]> wrote: > Is there a document/note describing the internals for the Radio/Dish > pattern? > Also, when you say multicast, I am assuming it is not reliable? > > Thanks! > > On Apr 26, 2016, at 3:54 AM, Doron Somech <[email protected]> wrote: > > Zeromq now have UDP transport, which you can use with the radio-dish > socket types. > > No docs yet so take a look at the following test: > > https://github.com/zeromq/libzmq/blob/master/tests/test_udp.cpp > > Both multicast and unicast should work. > > On Tue, Apr 26, 2016 at 6:26 AM, Ben Kloosterman <[email protected]> > wrote: > >> Just leave the UDP .. I use UDP as a separate channel and its so >> different that it should always be considered different eg no guarantee , >> no packet > 64K / MTU etc etc Forcing it to the sane structure is likely >> to be a bad idea. >> >> Ben >> >> On Tue, Apr 26, 2016 at 8:10 AM, TL;DR <[email protected]> wrote: >> >>> Hi, I just wanted to kick this conversation again. >>> >>> Does anyone have any pointers to patches or experimental versions that >>> provide UDP datagram transport without PGM? Just plain UDP for >>> unicast/multicast. >>> >>> I have migrated pretty much all services in a system over to ZeroMQ. >>> But there is a use case where I use UDP today, and haven't been able to do >>> so. I'm thinking there must be others (esp in finance) who are in the same >>> boat. >>> >>> PGM is a non-starter because auto-magical but late delivery is worse for >>> us than no delivery in this use case. These particular applications have >>> more complex behavior when they have missed something, and there is a >>> favored application level mechanism for detection of missed messages and >>> recovery. >>> >>> Thanks for any advice, >>> >>> _______________________________________________ >>> zeromq-dev mailing list >>> [email protected] >>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev >>> >> >> >> _______________________________________________ >> zeromq-dev mailing list >> [email protected] >> http://lists.zeromq.org/mailman/listinfo/zeromq-dev >> > > _______________________________________________ > zeromq-dev mailing list > [email protected] > http://lists.zeromq.org/mailman/listinfo/zeromq-dev > > > > _______________________________________________ > zeromq-dev mailing list > [email protected] > http://lists.zeromq.org/mailman/listinfo/zeromq-dev >
_______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
