[zeromq-dev] new API proposal: zmq_metasocket - your thoughts ?

Laurent Alebarde l.alebarde at free.fr
Mon Jan 20 11:23:16 CET 2014


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
>> zeromq-dev at lists.zeromq.org
>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
>
>
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20140120/3180e3f4/attachment.htm>


More information about the zeromq-dev mailing list