[zeromq-dev] need advice to debug an alternative to CURVE in a multithread test

Laurent Alebarde l.alebarde at free.fr
Fri Oct 25 16:43:56 CEST 2013

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 

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
> 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/20131025/fb233bfc/attachment.htm>

More information about the zeromq-dev mailing list