Great, it works ! Thanks Pieter for your help.
A pull request is following
-------- Message original --------
Sujet: Re: [zeromq-dev] proxying CURVE ?
Date : Tue, 03 Dec 2013 10:09:50 +0100
De : Laurent Alebarde <[email protected]>
Pour : Pieter Hintjens <[email protected]>
Thanks a lot Pieter for your deep answer. I understand now why I fooled
myself: the NULL mechanism is not a "nop" mechanism.
The first solution you propose is the "normal" usage. I don't want it
since I want to load-balance the handcheck.
The second one is not ZMTP and makes things harder for load-balancing.
So, I am going to *experiment a NOP mechanism*. Other names could be
NO_SECURITY or NO_HANDCHECK or PROXY. But I think NOP is the most
meaningfull since it will allow to use any ZMTP wire protocol with it
e.g. REQ, REP, ROUTER, DEALER, etc.
Client (DEALER, CURVE) --------- (NOP, ROUTER) Proxy (ROUTER, NOP)
------------ (CURVE, DEALER) Worker
Surrogate NULL NULL NULL NULL
<--------------------------------------- Server
--------------------------------------------->
I am going to keep the surrogate feature since it remains useful for it.
Your thoughts ?
Laurent
Le 02/12/2013 18:29, Pieter Hintjens a écrit :
On Mon, Dec 2, 2013 at 6:04 PM, Laurent Alebarde<[email protected]> wrote:
I took the hypothesis that only the greetings in ZMPT prevents different
mechanisms (say CURVE to NULL) to communicate.
This hypothesis is really inaccurate, though. The mechanisms are not
random strings in the handshake. They are encoded streams. It's true
that NULL and PLAIN share the same encoding (clear text). CURVE has a
different encoding. The handshakes themselves are also different. NULL
and PLAIN and CURVE all use different commands with different
meanings. There's no way to get NULL talking to CURVE by changing the
code. The protocols are not interoperable.
Let me give you one very simple example, and you may see why I'm
asking you to explain with protocol frames, not with code.
The client sends CurveZMQ HELLO to the proxy, to kick off the security
handshake. This is a command of 200 octets with a format as described
in RFC 26.
Now the proxy must decode that command and then respond with a valid
WELCOME command. That means, sending a valid CurveZMQ cookie.
There are two ways (no more, no less, that I can see) for a proxy to
do this. (A) it decodes the HELLO itself and creates the WELCOME
itself. Thus it speaks CURVE, has the right keys, etc. (B) it passes
the HELLO, unchanged to the worker, waits for a HELLO, and then passes
that unchanged back to the client. Thus it is a plain TCP proxy that
does not even implement the handshake. It doesn't use the NULL
mechanism, at all.
In the second option, the proxy MUST establish a connection with the
worker invisibly and immediately as it gets a client connection,
otherwise it cannot send on its HELLO command. Thus the end point must
be either calculatable, or provided by the client in some way,
_before_ the handshake, i.e. not in metadata but in the greeting
itself.
The simplest way to build such a proxy would probably be to use two
ZMQ_STREAM sockets, one at each side.
-Pieter
_______________________________________________
zeromq-dev mailing list
[email protected]
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
