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