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

[Matt Weinstein]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.zeromq.org/pipermail/zeromq-dev/attachments/20100925/a95391a4/attachment.htm