Great. I'm just doing some experiments to evaluate REQ/REP pattern. It seems that your implementation is completed.
Looking forward to reviewing your updates. On Mon, Mar 30, 2015 at 4:02 PM, ozamiatin <ozamia...@mirantis.com> wrote: > Hi, > > Sorry for not replying on [1] comments too long. > I'm almost ready to return to the spec with updates. > > The main lack of current zmq-driver implementation is that > it manually implements REQ/REP on top of PUSH/PULL. > > It results in: > > 1. PUSH/PULL is one way directed socket (reply needs another connection) > We need to support backwards socket pipeline (two pipelines). In REQ/REP > we have it all in one socket pipeline. > > 2. Supporting delivery of reply over second pipeline (REQ/REP state > machine). > > I would like to propose such socket pipeline: > rpc_client(REQ(tcp)) <=> proxy_frontend(ROUTER(tcp)) <=> > proxy_backend(DEALER(ipc)) <=> rpc_server(REP(ipc)) > > ROUTER and DEALER are asynchronous substitution for REQ/REP for building 1-N > and N-N > topologies, and they don't break the pattern. > > Recommended pipeline nicely matches for CALL. > However CAST can also be implemented over REQ/REP, using > reply as message delivery acknowledgement, but not returning it to caller. > Listening to reply for CAST in background thread keeps it async as well. > > Regards, > Oleksii Zamiatin > > > On 30.03.15 06:39, Li Ma wrote: >> >> Hi all, >> >> I'd like to propose a simple but straightforward method to improve the >> stability of the current implementation. >> >> Here's the current implementation: >> >> receiver(PULL(tcp)) <-- service(PUSH(tcp)) >> receiver(PUB(ipc)) --> service(SUB(ipc)) >> receiver(PUSH(ipc)) --> service(PULL(ipc)) >> >> Actually, as far as I know, the local IPC method is much more stable >> than network. I'd like to switch PULL/PUSH to REP/REQ for TCP >> communication. >> >> The change is very simple but effective for stable network >> communication. I cannot apply the patch for our production systems. I >> tried it in my lab, and it works well. >> >> I know there's another blueprint for REP/REQ pattern [1], but it's not >> the same, I think. >> >> I'd like to discuss it about how to take advantage of REP/REQ of zeromq. >> >> [1] >> https://review.openstack.org/#/c/154094/2/specs/kilo/zmq-req-rep-call.rst >> >> Best regards, > > -- Li Ma (Nick) Email: skywalker.n...@gmail.com __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev