Hi Devs,
From the exchange below, I wish to develop a complementary API for
libzmq. For the ones who have not followed the thread below, it would
enable to encapsulate ZMPT in a lower protocol, itself embedded in
another ZMTP layer (tunel backend). My goal is to be able to proxy CURVE
and so its handcheck end-to-end, but probably many other use cases are
possible.
Use case:
void *client = zmq_metasocket (ctx, ZMQ_DEALER, ZMQ_DEALER);
What it does:
|_______________client ____________________
_________tunel _______
Client --inproc---|||frontend| / backend
DEALER ZMQ_STREAM||| DEALER|
|
Normal API will adress the socket on the left. Everything else is
hidden. The second ZMQ_DEALER is for the tunel backend. It could be
ROUTER also, and possibly anything else.
The tunel will use a transport: "inproc://tunel00x", with x static and
incremented for each new metasocket.
The internal socket will be able to be configured with: zmq_setmetasockopt
With setmetasockopt, it will be possible to plug some utility functions
between the tunel frontend and backend.
Any suggestions or contributions welcome.
Cheers,
Laurent.
Le 18/01/2014 16:08, Laurent Alebarde a écrit :
Le 18/01/2014 11:58, Goswin von Brederlow a écrit :
On Fri, Jan 17, 2014 at 11:40:13AM +0100, Laurent Alebarde wrote:
Hi Devs,
I am doing some experiments (cf at the end for the goal) and wonder
where I could hook the beginning of a message both reading and
writing.
What I want to do is prepend an outgoing message and trim an
incoming message (for any mechanism looks simpler) when some option
is set.
Typically, when the option is set, when a new message is received, I
want to be able to store a certain amount of the first bytes in a
new mechanism buffer, and skip them. These bytes are experimental
and not ZMTP, so I have to skip or trim them to not hurt ZMTP. When
a message is sent, I want to initialise the buffer with a copy of
what I previously stored before ZMTP write the buffer. If it is
outpos, I will do outpos += store_size;
So, the question is where & when I should do that to not hurt ZMTP.
FYI, The aim of this experiment is to manage to achieve CURVE
proxying. My investigations and tests so far lead me to prepend the
client ID in every message sent to the CURVE worker, and that the
worker send back this information.
Cheers,
Laurent
How about this? (thread names in "")
"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.
Does that help?
If I catch it, my initial architecture attempt:
| ___________________server__________________
____________proxy___________
Client ------- frontend / backend ------- Worker
DEALER ZMQ_STREAM ZMQ_STREAM DEALER
CURVE CURVE|
becomes:
|_______________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|
which means I envelop ZMTP into whatever protocol I want, itself
envelopped again into ZMTP, otherwise said, I put my custom protocol
between two ZMTP layers ?
As I have adapted your suggestion to my need, I should be able to
simplify to:
|_______________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|
Thanks very much Goswin ! Very smart solution. I have to diggest it a
little.
Cheers,
Laurent
MfG
Goswin
_______________________________________________
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
_______________________________________________
zeromq-dev mailing list
[email protected]
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
