[zeromq-dev] Reactor Pattern using zmq_poll for ZMQ_SUB sockets

Praveen Baratam praveen.baratam+zmq at gmail.com
Tue Sep 28 09:08:31 CEST 2010


Dear Matt,

Thanks a lot for the reply.

It would be great if you can contribute an API page for ZMQ_REACTOR and
explain usage with inline examples similar to zmq guide. I don't know if i
am asking too much from an open-source developer but this piece of write up
will bring more value to your brainwork and contribution. i see that  there
are only few functions to document. Later users of your wrapper can
contribute use cases and modify the wiki to further enhance the whole thing.
I would definitely do the requisite if i can comprehend the usage properly
or i will contribute a wiki page if you can contribute API with inline
examples.

Thank you

Praveen



On Sat, Sep 25, 2010 at 9:29 PM, Matt Weinstein <matt_weinstein at yahoo.com>wrote:

> Praveen -
>
> Sorry, my fault, I'm buried in a project.
>
> The advantage of a "reactor" is easy construction of complex
> configurations.  There's no performance advantage per se, it just does the
> lookups for you.
>
> I've been using it for weeks in production systems, it works fine :-)
>
> I do need to add some clearer examples.
>
> Best,
>
> Matt
>
> On Sep 24, 2010, at 11:35 PM, Praveen Baratam wrote:
>
> Dear Chuck,
>
> Thanks for writing back.
>
> I did take a look into the zmq_reactor. the examples were not so clear and
> there is no documentation of the library and its api. i guess i should infer
> everything from the code.
>
> I was wondering whether this reactor will yield any performance benefit
> apart from provisioning a API. When it comes to normal sockets the benefit
> of ASIO (Reactor/Proactor pattern) is obvious because the OS kernel paves
> the path for it. Unless such an optimization exists inside zmq kernel and
> the added overhead of container (vector, unordered_map used inside reactor)
> lookup, modification etc is lesser than thread-per-socket approach, there is
> no point in using it.
>
> I guess the developers of ZMQ will be able to throw more light on this
> issue.
>
> Have you tried using zmq_reactor anytime?
>
> On Sat, Sep 25, 2010 at 12:57 AM, Chuck Remes <cremes.devlist at mac.com>wrote:
>
>>
>> On Sep 24, 2010, at 1:41 PM, Praveen Baratam wrote:
>>
>> I am trying to write a pub-sub server using ZMQ.
>>
>> The simplest way to describe my application is its a messaging server to
>> which clients connect using normal tcp sockets over intranet/internet. The
>> purpose is to exchange messages between them.
>>
>> I am using boost::asio to implement the tcp server part of the app. So
>> each client connection is represented as a session object with out a thread.
>> A single thread reads from all the client-connections/tcp-sockets and
>> publishes all incoming messages to a PUB socket. ZMQ_SUB sockets are
>> instantiated as part of session/connection object and are connected to this
>> PUB socket. The transport used is inpc://.
>>
>> Now the tricky part is client connections are managed using asio; means no
>> thread-connection pair. so i dont have a thread to wait on the SUB socket
>> attached to the connection. i guess i should use zmq_poll but it appears
>> complicated to work with if you have 10,000 SUB sockets in the server
>> process. It would have been great if there is a wrapper around zmq_poll  and
>> socket which would give something like ......
>>
>> s.subscribe("topic", callback, arg)
>>
>> Ideally a single threaded Reactor using zmq_poll should call the callback
>> function when there are messages waiting to be read from a socket similar to
>> how boost::asio library handles epoll internally for network sockets.
>> boost::asio uses proactor pattern but i guess i made my point.
>>
>> Kindly advise me in this regard.
>>
>>
>> Take a look at this project:
>>
>> http://github.com/mjw9100/zmq_reactor
>>
>> Also, you may want to search the mailing list archives for prior
>> discussions of this exact topic. I think the iMatix folks plan on building a
>> reactor library on top of 0mq but it will be part of an add-on library.
>>
>> cr
>>
>>
>>
>> _______________________________________________
>> 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: http://lists.zeromq.org/pipermail/zeromq-dev/attachments/20100928/23ea97bf/attachment.htm 


More information about the zeromq-dev mailing list