On Fri, Jun 24, 2011 at 11:11 AM, Henry Baragar <henry.bara...@instantiated.ca> wrote:
> the "slow joiner" syndrome... It has to be handled on a pattern-by-pattern basis. My belief today is that if you want synchronization over push-pull, you must switch to a router-based pattern, in the same way as we use routers to synchronize request-reply workers. It's on my list for 'reliable pipelines'. The model is you use a router-to-dealer dialog instead of push-to-pull, where dealers first tell the router they are ready, and the router can then switch workloads to dealers. One can then use dealer-to-dealer for work collection. > High Water Mark (HWM) configuration that offers little protection from > memory exhaustion when the number of anticipated connections is unknown (The > Guide: (Semi-)Durable Subscribers and High-Water Marks) Indeed. Limiting the number of connections comes under the general "making 0MQ more robust" category of work. > Message loss (due to network I/O buffers) even when using durable sockets > (The Guide: Transient vs. Durable Sockets) Durable sockets must be removed as a feature, eventually. Except in a few cases, they lead to memory loss. > I wonder how things would change if 0MQ used a "pull" model instead? Here is > what I mean by a pull model: Examine the use of ROUTER sockets in Ch4 of the Guide and you will see this is a pull model. You can use techniques such as credit-based flow control (i.e. recipient sends 'credit' messages which the sender uses to decide whether or not to send work to the recipient). CBFC (coming to the Guide soon) lets you control buffering in terms of bytes as well as messages. > My question is: Is there any possibility of these suggestions making it into > 0MQ? There are three ways to affect changes in 0MQ: * Learn the codebase and submit patches (this is difficult). If the maintainers refuse your patches you can fork the code, and try to convince others to use it (this is an absolutely valid way of working). * Offer money to the maintainers (they will still say 'no' if they don't like your designs). * Build your changes on top of 0MQ, as independent layers people can use or ignore as they like. Basically, you have to provide running code,or pay someone to make running code, and use that to convince others of your ideas. This is the filter which keeps our community healthy. Cheers Pieter _______________________________________________ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
