[zeromq-dev] Advice how to implement QoS for ROUTER-ROUTER or ROUTER-DEALER devices.

Artem Vysochyn artem.vysochyn at gmail.com
Wed Sep 25 17:40:32 CEST 2013


hi Matt,

Thanks for heads up.

First case -- (R/R) LRU-device. The whole thing that LRU-device hides from
client an info about workers (which is so cool!):  exact workers endpoints,
their number, who's dead, who's busy, their versions, and so on.  That's
why LRU-device plays role of a "smart-routing-guy", and
stores "workers-info" inside identity_cache(not hard to implement) which is
being populated when workers  send "presence notification" messages on LRU
backend.
Back to the question: >>> Why is it that you do not know which worker to
send the message to? <<<  Because R/R LRU-device is being driven by the
identity_cache, and since
this is "cache" thing, an info there is volatile, so essentially I can't
assert that identity_cache is full or not, because it's "timing thing".
Now, I have an issue -- I consumed message from frontend_socket, then want
to take identity from identity_cache, but ... identity_cache is empty. Like
this:

if (identity_cache.isNotEmpty()) {    //  time_0
  msg = frontend_socket.recv();
  id = identity_cache.poll();             // time_1
  ... here id may perfectly be null
  backend_socket.send(id + msg);
}


Second case -- (R/D) FAIR-device. You are absolutely right. But the trick
is that, the amount of workers which gobble messages from DEALER backend on
FAIR-device -- is volatile. At time_0 -- I may experience that HWM is full,
but at time_1 -- messages pass through. So the trick is -- where should I
store messages between time_0 and time_1 ?


>>> In either case can’t you monitor the scenario by knowing how many
messages you have received and how many replies you have sent back? <<<
Yes, this is what I'm implementing right now :)



2013/9/25 Matt Connolly <matt.connolly at me.com>

> Hi Artem,
>
> Your first case sounds like the lbbroker example. Why is it that you do
> not know which worker to send the message to?
>
> With your second scenario, reaching a HWM on the dealer socket would mean
> that you don’t have enough workers to keep up with the messages coming from
> the clients. If this is the case, isn’t the answer more workers?
>
> In either case can’t you monitor the scenario by knowing how many messages
> you have received and how many replies you have sent back?
>
> Regards,
> Matt
>
> On 25 Sep 2013, at 12:15 am, Artem Vysochyn <artem.vysochyn at gmail.com>
> wrote:
>
> > I'm working on creating top-notch rpc-framework (further RPCF) on the
> base of jzmq/zmq  and faced with serious design issue. Here's the deal, in
> my RPCF I'm going to use devices, especially LRU-device (via ROUTER-ROUTER
> mechanism), and more trivial FAIR-device (via ROUTER-DEALER mechanism).
> Regardless of *-device I inevitably will face the challenge of addressing
> some variant of QoS, here's how:
> >
> > 1. ROUTER-ROUTER (LRU-device)
> > -- remote_client sends request - a message via DEALER
> > -- request comes to LRU-device: poller.pollin(int) == true
> > -- now we consume a message from frontend ROUTER, and want to pass it
> further via backend ROUTER, ... but we can't because identity_storage
> doesn't host suitable identity.
> > ** now we got a problem: we consumed message from socket but couldn't
> forward it further. Also we can't drop message because client expecting
> reply. So what to do?
> >
> > 2. ROUTER-DEALER (FAIR-device)
> > -- remote_client sends request - a message via DEALER
> > -- request comes to FAIR-device: poller.pollin(int) == true
> > -- now we consume a message from frontend ROUTER, and want to pass it
> further via backend DEALER, ... but we can't because HWM is reached, so I
> get exception, catch it, and now what?
> > ** now we got a problem: consumed message from frontend, but couldn't
> forward it further.
> > Also we can't drop message because client expecting reply. So what to do?
> >
> > As you see, there's two main issues: what to do with a message which has
> been consumed from socket but wan't passed further because of some
> condition (in LRU case -- we failed to find suitable identity, for FAIR
> case -- HWM is reached on backend).
> >
> > Now, I'm here and asking for your advice regarding what to do with a
> message?
> >
> > So far, I implemented  mechanism which sends message back to its
> original sender with RETRY_CALL flag, and if receive_timeout wasn't being
> exceeded then client sends message again. But is this way to go? Maybe
> there're some other approaches which I don't see?
> >
> >
> > As usual, appreciate for the help in advance,
> >
> >
> >
> > _______________________________________________
> > 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20130925/c300a36c/attachment.htm>


More information about the zeromq-dev mailing list