[zeromq-dev] Incoming data on multiple sockets and fairness
gdiethelm at dcv.cl
Tue Mar 9 16:28:17 CET 2010
> The first thing to think about IMO is why do you need to handle
> 0MQ sockets. Each 0MQ sockets can handle unlimited amount of
> BSD sockets so in most cases there shouldn't be a need for that kind
> thing (unless you want to handle different socket types at the same
> in a single thread).
> Can you possibly explain the problem you are solving?
My "canonical" example is a data server: a process that reads lots of
data from a DB and waits for messages. These messages can be of three
1. Queries: these would be answered very quickly from the in-memory
data; the response will be sent somewhere else (specified by the query).
2. Updates: same as queries, except that processing the message entails
updating the DB (and the in-memory data).
3. Notifications: when a separate process has updated some information
that is important for this process.
Queries and Updates might be received from many different processes.
However, now that you mention it, maybe my mind is too fixed into the
BSD socket model, thinking I will need a separate 0MQ socket for each of
these processes. So the question here is: can my data server simply bind
an Upstream socket on a single address, and have all processes sending
Queries and Updates simply connect to that single endpoint? Of course,
the answer is yes... Right?
Now, I intend to receive Notifications on a Sub socket. The reason for
this is that I want to decouple the processes generating Notifications
from the processes receiving them (as discussed in a previous thread).
So, assuming I will only have one Upstream socket and one Sub socket,
how could I go about de-multiplexing between them?
> > (I believe this is called "edge-triggering" vs. "level-triggering").
> It's strictly level-triggered.
Please refresh my mind... This means the poll is signaled only once and
I must make sure to process everything that is pending before calling
poll again, right?
> > 3. I could also have a hybrid: many threads, as in #1, but they
> > put all incoming messages on a single queue. Then have one thread
> > more) fetching elements off this queue and processing them. It adds
> > latency and it forces me to use mutual exclusion for pushing
> > the queue tail and reading them off the queue head, but looks
> > me and I might even use the queue to handle retries.
> If you want to send messages from multiple threads to a single thread,
> simply bind a SUB socket to inproc endpoint in the receiving thread
> connect a PUB socket to the endpoint from each sending thread. That
> you'll need no mutexes.
Excellent, will keep this in mind. Thanks for your comments.
Declaración de confidencialidad: Este Mensaje esta destinado para
el uso de la o las personas o entidades a quien ha sido dirigido y
puede contener información reservada y confidencial que no puede
ser divulgada, difundida, ni aprovechada en forma alguna. El uso no
autorizado de la información contenida en este correo podrá ser
sancionado de conformidad con la ley chilena.
Si usted ha recibido este correo electrónico por error, le pedimos
eliminarlo junto con los archivos adjuntos y avisar inmediatamente
al remitente, respondiendo este mensaje.
"Before printing this e-mail think if is really necesary".
Disclosure: This Message is to be used by the individual,
individuals or entities that it is addressed to and may include
private and confidential information that may not be disclosed,
made public nor used in any way at all. Unauthorized use of the
information in this electronic mail message may be subject to the
penalties set forth by Chilean law.
If you have received this electronic mail message in error, we ask
you to destroy the message and its attached file(s) and to
immediately notify the sender by answering this message.
More information about the zeromq-dev