[zeromq-dev] issue : libzmq can send messages in a curve socket before the handcheck is finished !

[Laurent Alebarde]

Hi Pieter,

Thanks for your sunday answer :-) . What I see, as described below, is 
that when I block the handcheck with breakpoints in a multithreading 
debugging session (I know you don't like that ;-) ), the main test 
program can send data in a non blocking way and with a valid return value.

What I don't know is if the application data is queued somewhere (the 
pipe you are talking about ?) in a way the handcheck finaly goes on the 
wire first, or if application data may go on the wire first and be 
rejected by the peer until the handcheck is finished ?

All that came from my need to investigate how the handcheck behave in 
different scenari : we can have the broker set up with CURVE on the 
client side and NULL on the worker side, or the broker be a simple NULL 
proxy and the workers be configured with CURVE (I have not yet tested 
the second case - it may require more glue logic to ensure a client is 
always connected to the same worker in a same session).

Cheers,

Laurent

Le 20/10/2013 17:25, Pieter Hintjens a écrit :
> Hi Laurent,
>
> Messages would be queued up in the pipe for the connection until the
> handshake is complete, just as for any normal connection. What is the
> symptom you are seeing that makes you think there's something broken?
>
> -Pieter
>
> On Sun, Oct 20, 2013 at 3:33 PM, Laurent Alebarde <l.alebarde at free.fr> wrote:
>> I don't see any way to access is_handcheck_complete() or something
>> equivalent from a socket or any step in the send workflow, but I am very far
>> from mastering the libzmq code.
>>
>> So, I don't know how to solve this problem.
>>
>> Help from devs would be welcome please.....
>>
>>
>> Le 19/10/2013 12:28, Laurent Alebarde a écrit :
>>
>> Hi Devs,
>>
>> Observation : libzmq can send messages in a curve socket before the
>> handcheck is finished
>>
>> Problem : This is an unexpected behaviour that can break some user's program
>> logic, or impose to add more logic to deal with. Moreover, it happens in
>> some rare and so not reproduceable circumstances, I assume in multithread
>> applications.
>>
>> Test program : test_concurrency_curve.cpp based on test_proxy.cpp (not yet
>> merged - pulling request waiting). The number of clients and workers can be
>> parametered and are set here to 1, to facilitate debugging. The keys used
>> are the ones in the documentation, while in normal set-up, this test uses
>> different keys for each client (this is in comments).
>>
>> To reproduce the problem :
>> Add this test in your repository in the subdirectory tests and add the
>> following lines at the appropriate place inside tests/Makefile.am to take it
>> into account :
>>
>>                    test_concurrency_curve \
>> test_concurrency_curve_SOURCES = test_concurrency_curve.cpp
>>
>>
>> Set breakpoints here :
>>
>> test_concurrency_curve.cpp
>>
>> main, line 279 : msleep (1000);
>> client_task, line 121 : rc = zmq_send (client, content, CONTENT_SIZE, 0);
>>
>> curve_client.cpp
>>
>> zmq::curve_client_t::curve_client_t, line 41 : memcpy (public_key,
>> options_.curve_public_key, crypto_box_PUBLICKEYBYTES);
>>
>> curve_server.cpp
>>
>> zmq::curve_server_t::curve_server_t, line 47 : memcpy (secret_key,
>> options_.curve_secret_key, crypto_box_SECRETKEYBYTES);
>>
>> The break points in curve_client.cpp and curve_server.cpp prevent the
>> handcheck to be performed.
>> The break point in test_concurrency_curve.cpp / client_task is where the
>> send is performed while the handcheck is not.
>> I can follow the send until zmq.cpp / s_sendmsg , then ypipe.hpp /
>> zmq::pipe_t::write. As the return value is 0, I assume the message has been
>> sent. Then s_sendmsg returns 13, which correspond to the message size
>> actually sent. Finally, the assert in
>> test_concurrency_curve.cpp line 122 is ok.
>>
>> Expected behaviour :
>> Two possibilities :
>>
>> The send may be blocking until the handcheck is finished successfully,
>> possibly with a time-out.
>> The send is aborted with an error status, and the user application SHALL
>> check the connected status of the socket before using it.
>>
>> I remain at your disposal for further information.
>>
>> Cheers,
>>
>>
>> Laurent.
>>
>>
>>
>> _______________________________________________
>> 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/20131020/6b54cb40/attachment.htm>