[zeromq-dev] Multiplexing on top of TCP and subports
sustrik at 250bpm.com
Wed Sep 28 17:40:09 CEST 2011
> Just got round to reading this, very interesting. Though it was actually
> part of the knocking down the multiplexing idea (which does indeed seem
> to suck), I thought the advertising queue space acks were kind of
> interesting - I guess more generally it's a kind of flow control.
Yes. They are ACKs, same as those found in TCP, SCTP and whole bunch of
> It made me think, in the context of the other email thread about HWM
> (which admittedly is more about lack of HWM being set than a HWM being
My feeling was that most of the discussion regarding HWM was focused on
req/rep and push/pull, where it is desirable not to send a request down
a specific path unless we know that peer is ready to process it
immediately. In other words HWM should be exactly 1, including the data
in TCP buffers.
> if there's some value in hit HWM generating an upstream pub
> message on XPUB sockets. If you could signal the subscription set that
> the connection used, it would be easy to build systems to automatically
> spin up more downstream consumers
That doesn't make sense in case of PUB/SUB IMO. Messages are not
load-balanced, rather passed to all peers, meaning that having more
consumers doesn't help in handling the load in any way, it may even make
> or throttle message production
The problem here is that this way a single slow/dead consumer can
completely throttle the publisher and thus stop the flow of messages
even to all the well behaved consumers.
I don't know whether you've seen my email on this topic on the SP
Specifically, have a look at sections 4 and 5.
More information about the zeromq-dev