Hello all, On 10/12/2011 12:08, Martin Sustrik wrote: > My proposal thus is to use rate control to control the behaviour. For > example, user can set ZMQ_RATE to 10Mb/s and is expected to ensure that > the network is capable of that load. > > 1. The I/O thread will extract messages from the pipe at rate of 10Mb/s. > The network should be able to handle the load, so pushing these messages > into the network shouldn't be a problem. If it happens to be a problem, > I/O thread will start dropping messages so that draining of the pipe > continues at 10Mb/s. > > 2. The application thread will push massages to the pipe and if the pipe > is full it will *block*. >
A question related to this behavior. First, sorry for the delay before asking this question! Let's suppose that one of the subscriber for one reason or another enters a state where it is not able anymore to sustain the 10 Mb/s rate. This subscriber has a limited ZMQ_RCVHWM. After a while, the subscriber queue is full and it's the TCP buffer which will be used to store messages. Then the TCP buffer will also be full and for the publisher I/O thread, pushing new messages to this subscriber becomes a problem. Therefore the I/O thread will drop messages for this (and only for this) subscriber. The other subscribers still able to sustain the 10 Mb/s rate will not notice anything. Is the above correct? Will it also be the case if the host where the faulty subscriber is running crashes for any reason? Thank's for your answers Emmanuel _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
