[zeromq-dev] Blocking on multiple outputs

Pieter Hintjens ph at imatix.com
Thu Jun 2 17:09:19 CEST 2011

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

> As for HWM, dropping messages seems reasonable in this model. If there's not
> enough memory to serve the video feed, the video would hickup occassionally.

Nope, dropping messages would be the wrong response for this model,
because what you want is to tell the server, "stop reading this video
from disk, the client can't receive it". Dropping frames just damages
the stream, and forces the application to add some kind of recovery on
top. It's not realtime video, it's distribution.

What it needs, IMO, is a transport that has credit-based flow control.
Maybe something to experiment with via VTX, which will soon let me
make pluggable transports for 0MQ. The socket pattern here is really
simple (one to many, addressed like ROUTER) and the hard part is the
flow control.

It looks close to what we discussed about telling senders about the
receiver's HWM, but also needs to be visible to the sending
application so it can pause.


More information about the zeromq-dev mailing list