[zeromq-dev] Multiplexing on top of TCP and subports

Martin Sustrik sustrik at 250bpm.com
Wed Sep 28 17:40:09 CEST 2011

Hi Ian,

> 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 
other protocols.

> 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
> hit)

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 
it worse.

> 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 
mailing list:


Specifically, have a look at sections 4 and 5.


More information about the zeromq-dev mailing list