[zeromq-dev] RFC: finer control of socket type / behaviour

Pieter Hintjens ph at imatix.com
Mon Jun 2 13:11:21 CEST 2014

Returning EAGAIN on a full pipe might be a good improvement, though
it's unclear how an app could use this. Blocking seems problematic as
it exposes the app to failure when a single peer stops reading its

I agree that dropping messages is rather brutal in this case. However
it's also the most robust policy. You should perhaps not be sending
unlimited messages to a peer. There's suggestions in the Guide for
credit-based flow control that rates how much gets sent to any single


On Mon, Jun 2, 2014 at 11:19 AM, Goswin von Brederlow <goswin-v-b at web.de> wrote:
> On Wed, May 28, 2014 at 10:07:38AM +0200, Pieter Hintjens wrote:
>> This has been mooted before and I think it's a good idea in some ways.
>> Certainly to allow experimentation. However the current patterns do
>> kind of cover the sane use cases. It's hard to see what the point
>> would be, for instance, of blocking in a ROUTER socket when you can't
>> send a message. There's no real sense to that.
>> If you want to experiment with this, you can build custom socket types
>> on top of ZMQ_ROUTER and virtualize them, e.g. like the CZMQ zactor
>> model. Then if you get patterns that work well you've got arguments
>> for pushing this into libzmq.
>> -Pieter
> Except I can't change the "Action in mute state" frop "Drop" to
> "Block" or "EAGAIN". That means that messages get silently lost when
> one sends to fast or there is a temporary hickup in the network
> connection. E.g. when I reset a switch in the network I want messages
> to block till the switch is back.
> MfG
>         Goswin
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev

More information about the zeromq-dev mailing list