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). -- Paul