[zeromq-dev] Blocking on multiple outputs

[Pieter Hintjens]

On Wed, Jun 1, 2011 at 2:32 PM, Martin Sustrik <sustrik at 250bpm.com> wrote:

> I am not sure what the actual use case is, but what I infer is that the
> clients are not able to receive replies as fast as they produce requests
> (for example because the replies are huge while the requests are small).

Yes, this is exactly right. Tiny requests and massive responses. But
unicast, not multicast. And servers that can stream replies faster
than any client or network can handle them. So inevitable queue issues
in the server, unless some strong flow control is used.

To some extent it's a pub-sub model, and dropping data makes sense.
But it'd be smarter to use some form of credit-based flow control
since there's no multicast. Servers can sanely stop sending if they
know a particular client is slow or blocked.

The use case would be e.g. video distribution like Youtube, where
clients can request a particular video, and a server will stream it to
them.

-Pieter