[zeromq-dev] What differentiates connected peers on a ZMTP point of view ?

Goswin von Brederlow goswin-v-b at web.de
Mon Feb 10 10:43:10 CET 2014

On Thu, Feb 06, 2014 at 04:34:03PM +0100, Laurent Alebarde wrote:
> Hi Devs,
> I wonder please what differentiates connected peers on a ZMTP point
> of view ?
> To be more clear, let's consider this network:
> Client 1
> ---------------------------------------------------- Server
> Client 2 --------------------------------------------------/
> In ZMTP internals, I assume it creates a pipe associated with each
> origin address, and on an API side, it provides one identity
> associated to each one. So it creates one mechanism for each pipe
> and knows which instance to use every time in the stateful handcheck
> process. Is it correct ? there is a bijective association between
> the origin address and the identity ?
> Let's say that now we have a proxy in between:
> Client 1 ----------------------- Proxy
> ----------------------- Server
> Client 2 ------------------/92.123.321.22
> ZMTP on server side has no way to differentiate between Client1 and
> 2. Every message arrives in the same pipe which is the one
> corresponding to its closest peer: the proxy and its address. The
> only way for the server to differentiate the clients is at
> application level, when identities are stacked in the former frames
> of each message ?
> I am a bit confused. Can someone clarify for me please and point in
> the libzmq code what is taken into account to identify the pipes ?


A zmq message does not have just one identity. It has any number of
identity frames followed by an empty delimiter frame followed by data
frames. Normaly on each hop an identity frame is added. Depending on
the socket type when sending the first identity is used to decied
where to send the message and on recieve the identity of the sender is
added to show where it came from:

Client 1 sends:    '' 'request'                      # REQ adds ''
Proxy recieves:    <client 1> '' 'request'           # ROUTER adds <id>
Proxy sends:       <client 1> '' 'request'           # DEALER
Server recieves:   <proxy> <client 1> '' 'request'   # REP handles <id>s
Server replies     <proxy> <client 1> '' 'reply'     # REP handles <id>s
Proxy recieves:    <client1> '' 'reply'              # DEALER
Proxy sends:       <client1> '' 'reply'              # ROUTER strips <id>
Client 1 recieves: '' 'reply'                        # REQ strips ''

The REP/REQ sockets handle the identity frames for you so the
appliction never sees them. ROUTER adds/strips the first identity
automatically while DEALER lets you see them all.

> So, if my above hypothesis are right, as I want to manage to proxy a
> ZMTP mechanism like in the following:
> _______________client A___________________
> ____________________server_________________
> proxy                  __worker B __
>                     _________tunel A______ _____midpoint_____
> Client  --inproc--- frontend   /   backend ----tcp---- frontend /
> backend --inproc-- Worker
> CURVE |              CURVE
> |
> I have to create a pool of sockets in the proxy backend, say 1,000
> if I want to authorize 1,000 simultaneous connexions, and dispatch
> the clients to a sticky socket, and one and only one client per
> socket.
> \|/
> Client 1 ----------------------------------------------> socket 1:
> port 10001
> Client 2 ----------------------------------------------> socket 2:
> port 10002
> Client 1000 ----------------------------------------------> socket
> 1000: port 11000
> So, the worker is binded to all these ports. Still, does it work
> here ?  Does ZMTP creates a pipe per address on the worker side,
> even if they are binded to the same socket (the answer looks obvious
> but I prefer a confirmation) ?
> Cheers,
> Laurent

No. You use one socket for everything and add the identity of the
client to the message as you proxy it. Then on the reply you get the
identity of the client back so you know where to send it. Since ROUTER
adds the identity implicitly all a proxy has to do is real all message
frames from the ROUTER and write them to the DEALER and vice versa.
zmq does the rest as if it where magic.


More information about the zeromq-dev mailing list