[nanomsg] Re: issue with "received" message size
- From: Garrett D'Amore <garrett@xxxxxxxxxx>
- To: nanomsg@xxxxxxxxxxxxx, Paul Colomiets <paul@xxxxxxxxxxxxxx>
- Date: Tue, 11 Mar 2014 07:07:57 -0700
On March 11, 2014 at 1:44:16 AM, Paul Colomiets (paul@xxxxxxxxxxxxxx) wrote:
Hi,
On Tue, Mar 11, 2014 at 8:21 AM, Martin Sustrik <sustrik@xxxxxxxxxx> wrote:
>>> And quite possibly this should be applied not on a single nanomsg
>>> socket, but on something "lower" -- like an endpoint. (I've not
>>> examined your code fully here yet, but I imagine it might be
>>> possible to set up multiple "accept()" calls to handle different
>>> endpoints and different priorities. I got the sense this is
>>> where you were headed with the priority stuff. So we might want
>>> to rate limit connections coming from the internet, but not rate
>>> limit connections coming from localhost or even our local LAN.)
>>> I've some thoughts on rate limiting, if you'd like to explore we
>>> can discuss later.
>
> That can in fact be solved by receive priotities. Which are at the
> moment not exposed by the API -- because we haven't had clear use case
> for them.
>
> The idea being that with a lot of messages coming in, those from
> higher priority connections are being received by the user first. In
> other words, messages from lower priority connections are not passed
> to the user, thus TCP pushback is applied effectively resulting in
> rate-limiting of incoming data.
>
> The proposal thus: Let's re-introduce receive priority socket option.
>
I don't think such prioritization is useful enough to create another feature.
I think the obvious way to implement it is to use two sockets. (Note
that you need to have two different nn_bind() calls to use priorities too,
because nanomsg doesn't allow to have any distinction between two
accept()'ed connections on single endpoint).
You’re right that you’d want new metadata.
I guess in C land using poll to select between different sockets can be done.
But my thought was that a single application can avoid the need to poll
(nanomsg already does it!), and just do send/recv and let nanomsg figure the
scheduling beneath it. That seems to be the nanomsg philosophy.
I don’t have any particular “need” for this capability at present, so I’m happy
to spend whatever time is required to think about this and get it “right”
rather than rush to a solution.
Indeed, since this is not part of the “protocol”, the approach can differ in
different API implementations. Although it would be nice if there were
“semantics” around this that were at least common.
- Garrett
Other related posts:
