Hi all,
I have added the *zmq_proxy_open_chain* family functions in my
repository here (branch proxy_open_chain_AllIn1):
https://github.com/lalebarde/libzmq/commit/4fc96a516b59e75138cb4c48cb569c14a855073d
It follows the functions zmq_proxy_steerable, zmq_proxy_hook, and
zmq_proxy_chain already introduced in libzmq. Each one was built on top
of the other. Though, for zmq_proxy_open_chain,*I had to rewrite
zmq::proxy as a class*, in order to be able to add easily additional
features.
My original need was to*write applications more easily*, especially
*when I need an additional layer of protocol*, for example*to proxy
CURVE*. It is some months I am discussing solutions for it on the list.
I tried the NOP mechanism and surrogation (available on my repository,
branch /nop_and_surrogate_4_curve_proxying/) which does not solve this
problem, and I also tried to add a header to ZMTP (but this is too
complex and judged infeasible by Pieter). Goswin has suggested the
following solution
(http://lists.zeromq.org/pipermail/zeromq-dev/2014-January/024942.html):
"A" REQ <-inproc-> STREAM "Tunnel A"
"Tunnel A" DEALER <---tcp--> ROUTER "Midpoint"
"Midpoint" DEALER <---tcp--> ROUTER "Tunnel B"
"Tunnel B" STREAM <-inproc-> REP "B"
The "Tunnel A" and "Tunnel B" use a STREAM socket to get at the
on-wire data. Each data packet send they envelope into a ZMQ message
and send out their other socket. As the name suggests this tunnels
data from "A" to "B" without the "Midpoint" parsing the data. Now
the data can be anything, e.g. a CURVE encrypted and authenticated ZMQ
connection.
So I need to do this (I hope you have a large screen):
_______________client A___________________
____________________________server________________________________
proxy ________________worker B ___________
_________tunel A______
______midpoint____ _____tunel B______
Client --inproc--- frontend / backend ----tcp---- frontend /
backend --inproc-- frontend / backend --inproc-- Worker
DEALER ZMQ_STREAM DEALER ROUTER ROUTER
ROUTER ZMQ_STREAM DEALER
CURVE CURVE
or possibly this:
_______________client A___________________
____________________server_________________
proxy __worker B __
_________tunel A______ _____midpoint_____
Client --inproc--- frontend / backend ----tcp---- frontend /
backend --inproc-- Worker
DEALER ZMQ_STREAM DEALER ROUTER
ZMQ_STREAM DEALER
CURVE CURVE
So I need to chain proxies, allow hooks to deal with the identity and
build a backtrace, and for convenience and overall system performance,
minimize the number of threads.
*So, **the zmq_proxy_open_chain family functions allows:
*- proxy control: TERMINATE, PAUSE, RESUME (as zmq_proxy_steerable)
- proxy hook (as zmq_proxy_hook)
- chain proxies and end-points to use one poll and one thread, for
example, in the schema above, have Client, frontend and backend sockets
polled in the same thread.
- simple and quick prototyping.
The *documentation* is: /doc/zmq_proxy_open_chain.txt /
here:
https://github.com/lalebarde/libzmq/blob/proxy_open_chain_AllIn1/doc/zmq_proxy_open_chain.txt
The*test program* that shows all usages
is:/tests/test_proxy_open_chain.cpp /
here:
https://github.com/lalebarde/libzmq/blob/proxy_open_chain_AllIn1/tests/test_proxy_open_chain.cpp
*
**If you find it useful and want it included inside libzmq, please
answer with a "+1"*. If you think it is usefull but prefer to have it
available in an external library as czmq or other, just tell so. "-1"
are also welcome. If you find it useful, please feel free to detail
briefly what you think you can/will do with it.
If there are enough "+1", I will make a pull request. Anyway, it remains
on my repository, branch proxy_open_chain_AllIn1. The reasons I don't do
it yet are here:
http://lists.zeromq.org/pipermail/zeromq-dev/2014-February/025167.html
Cheers,
Laurent
_______________________________________________
zeromq-dev mailing list
[email protected]
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
