[zeromq-dev] Customizing Incoming Routing Strategy

Dorvin dorvin at tlen.pl
Thu Oct 23 22:15:08 CEST 2014


Ah... Then I misread your question, fixed myself on wrong track and 
introduced more confusion than help. Sorry.


W dniu 2014-10-23 21:55, Arnaud Kapp pisze:
> Well, fair-queue does *not* behave like FIFO.
> Imagine this simple code (in pseudo-code).
>
> sink = zmq_socket(ZMQ_PULL);
> sink.bind("inproc://my-sink");
>
> push1 = zmq_socket(ZMQ_PUSH);
> push1.connect("inproc://my-sink");
> push2 = zmq_socket(ZMQ_PUSH);
> push2.connect("inproc://my-sink");
>
> push1.send("msg1");
> push1.send("msg2");
> push2.send("msg3");
>
> // Reading on "sink" will give this:
> // msg1
> // msg3
> // msg2
>
> A fifo strategy would give:
> // msg1
> // msg2
> // msg3
>
>
> On 10/23/2014 09:27 PM, Dorvin wrote:
>> W dniu 2014-10-23 20:49, Arnaud Kapp pisze:
>>> Hello,
>>>
>>> Most sockets have a fair-queued routing strategy for incoming messages,
>>> and this makes a lot of sense *most* of the time.
>>>
>>> I would like to know if this behavior could be customized, for example
>>> to achieve a FIFO incoming strategy.
>>>
>>
>> It's behaving like FIFO. Otherwise it would not make sense. Imagine 2
>> PUB sockets connecting to one SUB. If only one PUB would send all
>> messages you would receive only first one and got blocked waiting for
>> second socket to send something.
>>
>> Treat "fair-queued" as opposite to ...hmmm... "priority queuing" which
>> would mean "process all messages from source A, then all messages from
>> source B, then...".
>>
>>
>> Cheers,
>> Jarek
>>
>> _______________________________________________
>> zeromq-dev mailing list
>> zeromq-dev at lists.zeromq.org
>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>>
> _______________________________________________
> 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