I could locate it inside stream_engine.cpp. It seems that the receive
mechanism via the greeting superceeds the socket option ?
So the first peer to send a message sets the mechanism for both. Is it
correct ?
Le 29/11/2013 14:05, Laurent Alebarde a écrit :
Thanks Pieter, you have saved my day.
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 ? Or is it simply impossible by design ? Can we
imagine an additional socket option to authorize it ? Could you please
elaborate onto the showstopper inside ZMTP ?
Le 29/11/2013 13:12, Pieter Hintjens a écrit :
This won't work at the ZMTP level. CURVE must talk to CURVE. You could
write a proxy that does raw TCP, and extends the CURVE handshake
across from client to worker. You could also use libcurve on top of
NULL, and do end-to-end security (that was the use case for libcurve).
On Fri, Nov 29, 2013 at 12:22 PM, Laurent Alebarde<[email protected]> wrote:
Hi all,
Is it right to proxy CURVE ? I mean:
CLIENT (CURVE) ------- (NULL) PROXY (NULL) ---------- (CURVE) WORKER
I have identified a condition: the PROXY SHALL be ROUTER/ROUTER, and SHALL
maintain a table that assign on client always to the same worker for the
socket TTL. With this condition fullfilled, can you see some other
showstopper for such an architecture ?
Cheers,
Laurent.
_______________________________________________
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
_______________________________________________
zeromq-dev mailing list
[email protected]
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
