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,
__________________________________________________________________________
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
