[zeromq-dev] NetMQ: Poller usage

[Giacomo Tesio]

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 <somdoron at gmail.com> 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 <giacomo at tesio.it> 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 <somdoron at gmail.com> 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 <giacomo at tesio.it> 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
>>>> 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/20130628/7f4628bc/attachment.htm>