On Wed, Jun 1, 2011 at 2:32 PM, Martin Sustrik <[email protected]> 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 _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
