I can't think of an example, I'm sure ZeroMQ guide have some. Anyway the thing is that if you don't want subscribers to loose messages you have to make sure all subscribers has connected to the publisher before you start publishing, in your case you have to wait for 200 subscribe messages, if you don't know the exact number of subscribers that can be a problem.
However as Diego suggested, if each subscriber is subscribed to a different topic maybe you better go with router / dealer, which also need synchronization, you can set the Identity of the clients to the topic (*only * if you have one subscriber per topic), set the router to mandatory and you will get an exception if the client is not connected yet (you should use multi part message, the first part is the topic/ identity and the other is the information). On Fri, Jun 28, 2013 at 12:31 PM, Diego Duclos <[email protected]>wrote: > If each subscriber is only subscribed to one topic, and each topic is only > used once, then XPUB/XSUB will work fine. However, it sounds like you > should be using a ROUTER/DEALER pattern instead ? > > > On Fri, Jun 28, 2013 at 11:02 AM, Giacomo Tesio <[email protected]> wrote: > >> Well, actually, I have ~200 subscribers (each on a different topic). So >> what should I do? >> >> I don't want to bore you: can you point me to the proper >> documentation/gist/example? >> >> >> Giacomo >> >> >> On Fri, Jun 28, 2013 at 10:40 AM, Doron Somech <[email protected]>wrote: >> >>> Almost, you just need to wait for the first subscription >>> (socket.Receive) on the publisher side... >>> >>> If you have more then one subscriber the story is a little different... >>> >>> >>> On Fri, Jun 28, 2013 at 11:30 AM, Giacomo Tesio <[email protected]>wrote: >>> >>>> Hi Doron, thanks for your kind help! >>>> >>>> So with an XPUB/SUB connection over an inproc transport no hand-made >>>> syncronization is needed? Have I understand correctly? >>>> >>>> >>>> Giacomo >>>> >>>> >>>> On Fri, Jun 28, 2013 at 9:19 AM, Doron Somech <[email protected]>wrote: >>>> >>>>> Hi Giacomo, >>>>> >>>>> The poller is actually a copy of the zloop from czmq, actually I'm not >>>>> big fun of the event pattern but I want to make it as close as possible to >>>>> CLRZMQ. >>>>> >>>>> 1. The start method is blocking, you should call if from a dedicated >>>>> thread. >>>>> 2. Stop(false) just signal the dedicated thread to stop but don't >>>>> actually wait the thread is stopped, this is good when you want to close >>>>> the poller but continue doing something else with your code, but if for >>>>> example you closing the application and want to wait until the poller is >>>>> completely stopped call it with true. >>>>> 3. Actually you cannot call Stop(true) from the dedicated thread, you >>>>> can call Stop(false) from the dedicated thread, but I don't have to >>>>> implement this kind of socket, you can just call Stop >>>>> 4. Just call the stop method >>>>> >>>>> Regarding the bonus question, you have to do some synchronization >>>>> magic to make it work, for the example let's call the socket which bind >>>>> server and the sockets which connect clients. So when the server binds no >>>>> client is connected yet (with inproc you have to bind before you can >>>>> connect), now if you will start send messages now the client will miss >>>>> them. >>>>> >>>>> After the client connected the client should send a signal message to >>>>> the server, after the server bind we wait for message from client, after >>>>> this the server can start publish messages. >>>>> >>>>> If we are talking about pub-sub pattern you should have a sub socket >>>>> as the client, xpub socket as server, now the client immediately send >>>>> subscribe message and the server wait for the first message... >>>>> >>>>> Doron >>>>> >>>>> >>>>> On Fri, Jun 28, 2013 at 3:23 AM, Giacomo Tesio <[email protected]>wrote: >>>>> >>>>>> Hi, I'm having an hard time understanding the NetMQ.Poller usage >>>>>> (here: >>>>>> https://github.com/zeromq/netmq/blob/master/src/NetMQ/Poller.cs). >>>>>> >>>>>> The fact is, it doesn't expose any Poll method. >>>>>> >>>>>> I guess that this is done in the aim of OOP desing. >>>>>> >>>>>> But I'm not sure about its correct usage. >>>>>> >>>>>> My insight is that after adding the sockets to the Poller, I should >>>>>> simply observe the sockets' events ReceiveReady and SendReady, but if so: >>>>>> >>>>>> >>>>>> 1. does the Start method block? If not, this should mean that I >>>>>> don't have to use it in a dedicated thread, right? >>>>>> 2. what are the pro/cons of Stop(false)? >>>>>> 3. one of the socket I added to the poller is a "control" one >>>>>> that send a "STOP" command when required. In the event handler can I >>>>>> stop >>>>>> the poller and remove the sockets? >>>>>> 4. what should I do to cleanup things (before context >>>>>> disposition)? >>>>>> >>>>>> Moreover I'd like to know if the socket events will ever be fired >>>>>> from sockets that aren't in a Poller, or not. >>>>>> >>>>>> >>>>>> Finally a bonus question (be patient, I'm a newbie here): I've read >>>>>> that with ZeroMQ I can loose a few messages at connection startup (even >>>>>> if >>>>>> I start the receiver before the sender): does this apply to inproc >>>>>> sockets >>>>>> too? >>>>>> >>>>>> >>>>>> Thanks a lot. >>>>>> >>>>>> >>>>>> Giacomo >>>>>> >>>>>> _______________________________________________ >>>>>> 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 >> >> > > _______________________________________________ > 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
