It means exactly what I wrote in my first message : proxying CURVE. Let
me copy/paste it here:
CLIENT (CURVE) ------- (NULL) PROXY (NULL) ---------- (CURVE) WORKER
With the following constraints on the proxy: it SHALL be ROUTER/ROUTER,
and SHALL maintain a table that assign on client always to the same
worker for the socket TTL.
So it makes sense. It has several advantages: load balance handchecks,
enable heavier mechanisms, hide the handcheck in workers, behind the
front-end.
I am going to test some additional options to distinguish the socket
mechanism option from the puplished one (the one communicated on the
wire to the peer), so that both client and worker can use CURVE, but
exhibit NULL to the proxy. Of course, the proxy here is not proxy.cpp,
but a special proxy taking into account the constraints depicted above.
CLIENT (CURVE)(NULL) ------- (NULL) RR_PROXY (NULL) ---------- (NULL)
(CURVE) WORKER
If it works, are you interested by a pull request ? Of course, default
beheviour will be unchanged.
Cheers,
Laurent.
P.S. : I am not used to eating my feet. The idea is just disgusting.
Le 29/11/2013 15:16, Pieter Hintjens a écrit :
On Fri, Nov 29, 2013 at 2:05 PM, Laurent Alebarde <[email protected]> wrote:
I don't want to use raw TCP, and I would prefer sticking to libzmq. So, I
raise the question: wouldn't it be a good idea to be able to proxy CURVE as
depicted below ? Is it today impossible as a design choice to avoid misuse ?
How can a CURVE peer talk to a NULL peer? What does that even mean?
It's like asking whether you can eat with your foot... even if you put
the words together, it is nonsensical. It's not disabled by design.
-Pieter
_______________________________________________
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
