FYI :
Here is how I produce traces and key pairs per client. I also use a
dedicated key pair in the server for each client : zmq_utils.h
<http://pastebin.com/iCDJa5Ab> , zmq_utils.cpp
<http://pastebin.com/UTwrCep9>
Here is test_concurrency_parano.cpp <http://pastebin.com/EtBgj9jj> - the
set_socket_option(keys) are replaced by one option which is the id of
the client.
And one example of trace <http://pastebin.com/uwv76rju>.
The client retrieve the keys in<http://pastebin.com/ZZW4Fxx0>
produce_hello <http://pastebin.com/hjv18zAW>
The server in produce_welcome <http://pastebin.com/VQGb9N2d>, from the
cert id sent by the client.
Le 25/10/2013 16:22, Laurent Alebarde a écrit :
Hi Devs,
As some of you know it, I am working on an experimental alternative to
CURVE: PARANO (because I am paranoïd of course ;-) ). Typically, I
started by dupplicating the CURVE frame as a clone, check everything
was right, and then started step by step to change produce/process
methods. The equivalent of test_security_curve.cpp,
test_security_parano.cpp is working. Then I made a multithread test
based on test_proxy.cpp for curve: test_concurrency_curve.cpp which
works well, and then port it to PARANO: test_concurrency_parano.cpp.
With one client it is ok, but with several ones, I have some
unreproduceable destruction/re-construction of the mechanism. For
example, with 3 clients, It can be once the mechanism for client n°2,
and the other time no one, and another time two of them, or twice the
one of the same client. When the mechanism_t object is destructed
(destructor method called), the handcheck is process again of course,
and finally, the messages are sent normally. So if I don't care, it
delivers what it has to deliver. But it is not clean.
When I use the multithreaded debugger, it seems to be worse, with more
mechanisms destruction/re-construction. My question is:
*Considering CURVE, Is there some time delay I should deactivate when
some threads are paused ?*
Cheers,
Laurent.
P.S.: I plan to publish and propose PARANO when I will create my
company. The RFC is in progress.
_______________________________________________
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
