[zeromq-dev] QoS / prioritization status

[Gary Strangman]

Hi Martin,

That does indeed help. Just knowing that 0MQ encourages separate sockets for
separate priorities is quite useful. That approach doesn't help when I need
to re-prioritize a message that has been queued but before it has been sent
(which would, I guess, require "popping" a message off e.g. a lower priority
queue and moving it to a higher priority one), but I can probably live with
that limitation for now.

-best
Gary

On Fri, Jun 24, 2011 at 3:54 PM, Martin Sustrik <sustrik at 250bpm.com> wrote:

> Hi Gary,
>
>
>  1) Have there been changes/additions in 0MQ since the above thread that
>> might provide added support for either 0MQ-level or application-level
>> prioritization of messages? (FWIW, I'm OK with some messages getting
>> higher priorities than requested, via message-bunching.)
>>
>
> No. No changes in this respect.
>
>
>  2) Are there any (related?) 0MQ features or patterns that might help
>> optimize message flow through a (known) network bottleneck?
>>
>
> The important point to take into account here is that TCP enforces strict
> ordering of data and thus you get head-of-line blocking syndrome not matter
> what you do on application level.
>
> That's the reason why 0MQ encourages using different sockets for different
> kinds of data, eg. normal vs. urgent.
>
> The receiving application can then poll on 2 sockets, processing messages
> from the "urgent" one before anything else.
>
> As for the ToS bits, these are meant to be set by the networking stack.
> Having two sockets using different ports allows you to set your networking
> hardware and/or networking stack at the endpoints in such a way that it sets
> appropriate ToS bits on the urgent feed but not on the normal feed.
>
> HTH
> Martin
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20110624/76454461/attachment.htm>