[zeromq-dev] zmq_proxy_open_chain family functions for easy protocol and proxy development

Laurent Alebarde l.alebarde at free.fr
Wed Feb 5 15:43:01 CET 2014


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









-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20140205/01ff1948/attachment.htm>


More information about the zeromq-dev mailing list