I'm going to assume this is your first real work with ZeroMQ (based on your earlier question about binding), and so I'm going to point you to the FAQ. http://zeromq.org/area:faq
Please do learn the basics by working through the examples, before attempting anything complex. On Tue, Sep 24, 2013 at 4:15 PM, Artem Vysochyn <[email protected]> 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 > [email protected] > http://lists.zeromq.org/mailman/listinfo/zeromq-dev > _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
