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
<[email protected]> 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
[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
