> The first thing to think about IMO is why do you need to handle multiple > 0MQ sockets. Each 0MQ sockets can handle unlimited amount of underlying > BSD sockets so in most cases there shouldn't be a need for that kind of > thing (unless you want to handle different socket types at the same time > 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 kinds: 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 simply > > put all incoming messages on a single queue. Then have one thread (or > > more) fetching elements off this queue and processing them. It adds more > > latency and it forces me to use mutual exclusion for pushing elements on > > the queue tail and reading them off the queue head, but looks "saner" to > > 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 and > connect a PUB socket to the endpoint from each sending thread. That way > you'll need no mutexes. Excellent, will keep this in mind. Thanks for your comments. -- Gonzalo Diethelm ----------------------------------------- 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. _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
