Hi Joel, What version of zmq are you using?
https://github.com/zeromq/libzmq/commit/a0cecc718d3d95279dcc7b0d9b6c1d09fb4cfd97 The patch let send method block when the pipe is full with the mandatory option. Or if you send message with DONTWAIT, it will return -1 with EAGAIN. Thanks Min On Apr 6, 2013, at 12:30 AM, Pieter Hintjens <[email protected]> wrote: > Hi Joel, > > It's indeed possible ROUTER doesn't reliably report HWM. To be > checked; this would seem to be an error in the mandatory > functionality. > > You might consider using credit based flow control. It isn't that > complex and gives you more accurate control over the flow of messages. > When a client isn't responding, the server knows up front, before > messages get lost. > > There is a simple ROUTER-DEALER CBFC model explained in Chapter 7. > > -Pieter > > > > On Fri, Apr 5, 2013 at 10:13 AM, Joel Lauener <[email protected]> wrote: >> Currently I’m doing some testing with the DEALER-ROUTER combo. This test >> involve a single ROUTER sending messages to a single DEALER. This emulate >> one of our use case were the server is sending notifications to a client. >> What I’m doing now is I’m slowing down the client so it is unable to process >> all the received messages. >> >> >> >> Looking at the TCP buffers I see a correct behaviour, client rcv buffer >> fills up, then server snd buffer fills up. However when the snd buffer is >> full, the ROUTER still accepts my messages but seems to internally drop >> them. I’m using non-blocking send with the mandatory option enabled, but >> still I receive no error. Is this the expected behaviour? >> >> >> >> Is there some documentation (beside the code ;) about the internals of >> ROUTER sockets? I guess there is one “main” queue that is dispatched to many >> “client” queues. If so, this would explains why send doesn’t fail because >> the “main” queue is not full and the message is dropped while dispatching. >> That would also explains why HWM doesn’t work as I would expect (because it >> only affects the “main” queue). >> >> >> >> Using a DEALER-DEALER pattern it works as expected. The send calls fail, >> which allows the server to be aware of the lost message. This last point is >> very important for us because if a notification is lost the server must, at >> least, log it. >> >> >> _______________________________________________ >> zeromq-dev mailing list >> [email protected] >> http://lists.zeromq.org/mailman/listinfo/zeromq-dev >> > _______________________________________________ > zeromq-dev mailing list > [email protected] > http://lists.zeromq.org/mailman/listinfo/zeromq-dev _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
