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 <[email protected]> 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
[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
