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

[Laurent Alebarde]

And a 4th one: have the security protocol (CURVE or PARANO) build on top 
of libzmq or czmq. They would simply use the libzmq default mechanism NULL.

BTW, what are the pros/cons to have a security protocol built has a 
libzmq mechanism (as CURVE today), or built on top of libzmq ?


Le 08/01/2014 23:08, Laurent Alebarde a écrit :
> 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 queued.
>
> 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
>
>
>
> _______________________________________________
> 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/20140109/8b1eb5f2/attachment.htm>