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
