[zeromq-dev] Theoretical whitepaper on 0MQ

[Martin Sustrik]

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