[zeromq-dev] ZMQ_STREAM interraction with ZMTP ?

[Laurent Alebarde]

After some checks, in my "NOP mechanism and the surrogate feature" 
solution, I did not do these errors. So I am out of ideas now.

Any help please for any of the two attempts:
1) ZMQ_STREAM proxy
2) ZMQ_NOP proxy with surrogation

Le 06/12/2013 19:12, Laurent Alebarde a écrit :
> After corrections, the behaviour remains the same.
>
> I have tested that when I shunt the proxy, it works (cf comments with 
> "shunt the proxy" - note: the worker have to become a ROUTER), so both 
> client and worker are right.
>
> I have pushed the corrections on my repository, with a comment:
> https://github.com/lalebarde/libzmq/commit/9a1eb95feb79d8a1347df34a21eeb809f0b8ccfe#commitcomment-4795437
>
> If someone wants to help here, you are welcome.
>
> I go back to my first solution with the NOP mechanism and the 
> surrogate feature for the reasons provided below, and with some hope 
> it will work.
>
>
>
> Le 06/12/2013 18:01, Laurent Alebarde a écrit :
>> Hi Pieter,
>>
>> I have found one big show-stopper in my code below as in the one for 
>> test_surrogate_curve with NOP mechanism and surrogate feature:
>>
>> In both cases, I am configuring the client socket with:
>>
>>     int as_server = 0;
>>     int rc = zmq_setsockopt (worker, ZMQ_CURVE_SERVER, &as_server, 
>> sizeof (int));
>>     assert (rc == 0);
>>
>> which *sets the NULL mechanism* and explain what I did observed !
>>
>> This API is very not natural for me. It is said to "save" works to 
>> libzmq users and simplify their code, to the detriment of rationality 
>> IMHO, which I consider the natural way to do things.
>>
>>
>>
>> Le 06/12/2013 16:26, Laurent Alebarde a écrit :
>>> Here is my test code (one single commit in my master) : 
>>> https://github.com/lalebarde/libzmq/commit/2d38f19249d2a4f5dcc4d1d5ec907a092d6a8266
>>>
>>> It implements:
>>> Client (DEALER, CURVE) ---- (STREAM) Proxy (STREAM) ----- (CURVE, 
>>> DEALER) Worker
>>>
>>> I have simplified it as most as possible. So only 1 client and 1 
>>> server are possible.
>>>
>>> What I can observe is that :
>>> 1) the curve_client_t object doesn't receive the curve keys set with 
>>> zmq_setsockopt
>>> 2) an unexpected null_client_t object is created
>>>
>>> So, I wonder if I use some functions with the STREAM socket I should 
>>> not use, and that activates the stream_engine ?
>>>
>>>
>>> Le 06/12/2013 14:29, Pieter Hintjens a écrit :
>>>> On Fri, Dec 6, 2013 at 2:21 PM, Laurent Alebarde<l.alebarde at free.fr>  wrote:
>>>>
>>>>> It is not even clear to me and cannot be seen with the debugger. I can only
>>>>> make deductions from the assertion that the curve socket cannot send a NULL
>>>>> greeting, then I assume that either it is the STREAM socket which sends it,
>>>>> either it is a fake of the curve socket when it receives something.
>>>> This makes zero sense to me, sorry.
>>>>
>>>> The curve socket can only send curve commands as defined in the CURVE RFC.
>>>>
>>>> The stream socket has to read and parse these commands.
>>>>
>>>> Why on earth are you looking at code or debugging it? The facts here
>>>> apply only to the protocol, i.e. what is sent on the wire.
>>>>
>>>> -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
>
>
>
> _______________________________________________
> 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/20131206/f7a32c01/attachment.htm>