gonzalo diethelm wrote: > 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?
Yes, right. As the queries and updates are the "same" thing (from the business logic point of view) it makes sense to process them using a single socket. Doing so would guarantee fair balancing. > 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? It seems that "Queries" (including updates) and "Notifications" are indeed distinct things (from the business logic POV) so there should be two separate sockets. Handling multiple sockets requires using zmq_poll. As for fairness guarantee, it depends on your requirements. You may, for instance, want to process notifications before queries etc. With zmq_poll you are free do process the messages in whatever order you like. >>> (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? No. The other way round. Poll will be signaled every time there's a message to read in the socket. Martin _______________________________________________ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
