Hi Ian, > Excellent doc Martin. Interesting points on the principles. I know that > you were intentionally using parts of ømq as examples where the > principles weren't being followed, but I thought the end-to-end behavior > and interjection principles had some interesting consequences, for > example for push/pull.
Yes. Parallelised pipeline pattern is not uniform. As I've already noted on SP mailing list, it's important to separate 0MQ as product and SP as generic scalability layer. 0MQ as a product can support even not perfectly scalable patterns, if that's what people want. SP as a layer/specification should on the other hand focus on perfect scaling. In the future, if SP ever gets into shape and 0MQ implements it, 0MQ can be simply viewed as SP implementation with non-standardised non-scalable add-on patters. > As far as I can see the load balancing behavior will break the > interjection principle - if I have 1 client pushing to three nodes, and > I put 2 behind an intermediary, as in the example, I will increase the > share of the load on the 1st (still directly connected) node from 33% to > 50%. It depends on what you consider to be "observable behaviour". I would say the interjection principle can be violated by functional differences but not performance differences. If you opt to consider performance difference as breaking the interjection principle, there's no way to make it work. Adding a middle node is going to add latency if nothing else. > It would seem possible to have a kind of XPULL/XPUSH socket type > may have the ability to be informed of availability, similarly to the > subscription chaining in XPUB, to allow more accurate distribution - > though this could be one of those ideas that's very bad in practice! I am not sure whether I get you correctly. I would say the PUSH socket is informed about availability of peer PULL sockets via HWM. I.e. when HWM on particular connection is reached, PUSH socket stops sending more work on that connection and load balances the work between the remaining connections. Martin _______________________________________________ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
