[zeromq-dev] I need some advice please for StreamQ-Proxy

Laurent Alebarde l.alebarde at free.fr
Wed Jan 8 23:08:52 CET 2014

One idea, let's call it case 3:

A worker can be paired with many clients, but only one in the hancheck 
phase. For any client which has passed the handcheck, the proxy prepends 
a frame with its identity when forwarding to the worker. The worker 
resends this first frame in its answer. This frame is build with a size 
not met in the mechanisms used. Then when the proxy receives a message 
from a worker, if it is of this size, it uses the first frmae to 
identify the client to forward to. Otherwise, it uses its own pairing table.

The proxy needs some knowledge on the mechanisms used to know when a 
handcheck is passed.

Besides, when a new client arrives and all workers are already in a 
handcheck phase, either it is rejected with a retry later, either it is 

Your thoughts ?

Le 08/01/2014 22:38, Laurent Alebarde a écrit :
> Hi Pieter,
> Thanks for your answer.
> Yes, your first case has been the direction I have followed from the 
> advices you have had already given to me, and put in a spec here : 
> https://github.com/lalebarde/streamq-proxy/blob/master/SRD.md
> In the test, I have added some CURVE handcheck checks, but just for 
> tests . I agree this proxy SHALL be agnostic. I am a step above where 
> I need to pair a client with a worker. One client has one worker, but 
> one worker may have several clients. That's where I fail now.
> I don't need to access the identities hidden by CURVE since the 
> ZMQ_STREAM socket use its own. That's al-right. But when a message 
> comes back from the worker,*I have no information available to know 
> which of the clients assigned to this worker to choose from.*
> Let's say I have clients C1, C2, C3, and workers W1, W2:
>                 proxy assigns identity IdW1 ------------ W1
> proxy assigns identity IdW2 ------------ W2
> C1 ------------ proxy assigns identity IdC1, and pairs IdC1 with IdW1, 
> then messages can
>                 be forwarded in both directions and it works.
> C2 ------------ proxy assigns identity IdC2, and pairs IdC2 with IdW2, 
> then messages can
>                 be forwarded in both directions and it works.
> C3 ------------ proxy assigns identity IdC3, and pairs IdC3 with IdW1, 
> then messages can
>                 be forwarded to worker, BUT when the worker answer, 
> *the proxy has no mean**
> **                to choose between **IdC1 and IdC3 when there are 
> concurrent **connexions*.
> Case 2 may be al-right for CURVE, but is not satisfactory for PARANO.
> At this point, I only foresee a third case, where I use only NULL, and 
> define a high level protocol build on top of libzmq or czmq, which 
> embeds PARANO.
> But if you have a solution to proxy CURVE or whatever else while 
> keeping the used mechanism in libzmq, in a context of concurrent 
> connexion, I will take it.
> Cheers,
> Laurent.
> Le 08/01/2014 19:52, Pieter Hintjens a écrit :
>> On Wed, Jan 8, 2014 at 7:03 PM, Laurent Alebarde<l.alebarde at free.fr>  wrote:
>>> I have to pair clients and workers.
>> Identity information is encrypted. That means you have two basic design options:
>> * a pass-through proxy that does not understand CURVE, and simply
>> shuffles packets from one side to the other. This should be fairly
>> simple: read a frame from a stream socket, write to another stream
>> socket.
>> * a known broker, which acts as a CURVE server (to clients) and CURVE
>> client (to workers, I guess). This is then a classic ZeroMQ broker
>> which can do stateful routing from clients to workers.
>> In the first case you can create a switched connection between a
>> client and a random worker (since both offer automatic identities via
>> the STREAM socket). However there is no way (by design) to get access
>> to any metadata provided by clients or workers, including their
>> identities. That is what CURVE is protecting.
>> Does this help?
>> -Pieter
>> _______________________________________________
>> 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/20140108/47ecc5f8/attachment.htm>

More information about the zeromq-dev mailing list