On Tue, Apr 20, 2010 at 09:57:42PM +0200, Pieter Hintjens wrote: > Perhaps a general solution is to move the 0MQ work to a separate > process and talk to that. It can run at full speed and queue stuff up > for the Ruby app to take when it needs it.
That is logical. However, then you need to design a protocol to run between the ruby app and the messaging daemon. If that protocol is 0MQ, then you've removed the need for the daemon. If it's a different protocol, it could be designed to run down a single channel (e.g. stdin/stdout to a child process). I think it would need to allow: * Overlapping (tagged) REQ/REP * Individual messages to be labelled with their destination, similar to topics * Per-destination flow control, to avoid a backlog to one destination preventing messages being sent to another destination If such a protocol existed, it would be tempting to run it directly on the wire instead of 0MQ. Or, the local protocol could work differently (e.g. synchronous polling for pulling newly-arrived messages out of the daemon, rather than having them arrive asynchronously) The main purpose of the daemon would then be to establish pools of connections, and round-robin message delivery. (I'd also like to see it implement efficient persistent local queues, but that's new functionality) Regards, Brian. _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
