Re: [zeromq-dev] shutting down proxy device cleanly with pyzmq
Beautiful. I updated my pyzmq install using "python setupegg.py develop" and it's all working like butter. Thanks! --ap On Tue, Oct 22, 2013 at 11:39 AM, MinRK wrote: > This is fixed in pyzmq master, so nothing more to do but get around to a > release. > > > On Fri, Oct 18, 2013 at 9:46 PM, Sideropoulos, Alexander < > alexan...@thequery.net> wrote: > >> 13.1.0 >> >> I have attached an interactive session log which shows the issue as >> clearly as possible. I might just be doing something dumb, though... >> >> Thanks for looking into it. >> --ap >> >> >> On Wed, Oct 16, 2013 at 12:52 AM, MinRK wrote: >> >>> What version of pyzmq? Can you provide a complete failing example? I >>> can't reproduce this in pyzmq master, so maybe I have fixed it since 13.0. >>> >>> ___ >>> zeromq-dev mailing list >>> zeromq-dev@lists.zeromq.org >>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev >>> >>> >> >> ___ >> zeromq-dev mailing list >> zeromq-dev@lists.zeromq.org >> http://lists.zeromq.org/mailman/listinfo/zeromq-dev >> >> > > ___ > zeromq-dev mailing list > zeromq-dev@lists.zeromq.org > http://lists.zeromq.org/mailman/listinfo/zeromq-dev > > ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] what do I do bad with zmq_threadstart ?
Thanks both of you Pieter and Mikko,
Oh yes, this code is not the best one I tried:
threads[i] = zmq_threadstart (&client_task, (void*) args);
threads[i] = zmq_threadstart (&client_task, reinterpret_cast
(args));
Finally, in an other try, I did let client_task (void **) :-[
Le 22/10/2013 18:35, Pieter Hintjens a écrit :
You have to cast the args to (void *) when calling zmq_threadstart,
and cast the void * argument back to void ** in the child thread.
On Tue, Oct 22, 2013 at 6:29 PM, Laurent Alebarde wrote:
Hi Devs,
I am trying to use zmq_threadstart. My first test passing ctx as args works,
but I need now to pass two arguments. So I tried many ways and all the time
it ends with a compilor insult :
error: invalid conversion from 'void (*)(void**)' to 'void (*)(void*)'
[-fpermissive]
In file included from ../tests/testutil.hpp:24:0,
from ../tests/test_concurrency_parano.cpp:20:
../tests/../include/zmq_utils.h:94:18: error: initializing argument 1 of
'void* zmq_threadstart(void (*)(void*), void*)' [-fpermissive]
make: *** [tests/test_concurrency_parano.o] Error 1
Here is my code exerpt :
struct arg_t {
void* ctx;
uint8_t id[8];
};
for (int i = 0; i < QT_CLIENTS; i++)
{
arg_t* args = (arg_t*) malloc(sizeof (arg_t)); // it is up to the
thread to free it
args->ctx = ctx;
int rc = build_test_stuff(i, args->id);
assert (rc == 0);
// start client thread with id
threads[i] = zmq_threadstart (&client_task, args);
}
I read many posts on stackoverflow and elsewhere with the same problem with
pthread_create, but it has not helped me.
Any idea please ?
Laurent
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] shutting down proxy device cleanly with pyzmq
This is fixed in pyzmq master, so nothing more to do but get around to a release. On Fri, Oct 18, 2013 at 9:46 PM, Sideropoulos, Alexander < alexan...@thequery.net> wrote: > 13.1.0 > > I have attached an interactive session log which shows the issue as > clearly as possible. I might just be doing something dumb, though... > > Thanks for looking into it. > --ap > > > On Wed, Oct 16, 2013 at 12:52 AM, MinRK wrote: > >> What version of pyzmq? Can you provide a complete failing example? I >> can't reproduce this in pyzmq master, so maybe I have fixed it since 13.0. >> >> ___ >> zeromq-dev mailing list >> zeromq-dev@lists.zeromq.org >> http://lists.zeromq.org/mailman/listinfo/zeromq-dev >> >> > > ___ > zeromq-dev mailing list > zeromq-dev@lists.zeromq.org > http://lists.zeromq.org/mailman/listinfo/zeromq-dev > > ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] JeroMQ/ZeroMQ transparent acceleration with Fast Sockets
Hi Pieter! UFS is a preloadable library that captures standard sockets and uses its custom protocol in case the communicating peer also has UFS, otherwise it falls back to TCP sockets. Right now we are still working on UFS but there is a free version to test, available on request for anyone interested in playing with UFS. We will update the figures with throughput results, in this particular case replacing TCP is not so important for small messages so the benefit is lower in these cases. Finally, our libraries replace sockets on loopback and RDMA networks. For accelerating sockets in other environments I would recommend first buying a low-latency/RDMA network, as the network card itself would be a major bottleneck :D Best regards, Guillermo On Tue, Oct 22, 2013 at 7:26 PM, Pieter Hintjens wrote: > Hi Guillermo, > > Interesting stuff. Is UFS an add-on module on Linux that replaces > standard sockets? It would be interesting if there was a free version > available for people to test. > > I see the performance difference for C++ over Infiniband is about 30%. > It would be useful to have figures for throughput, and also comparison > of real TCP (not loopback) on normal sockets vs. UFS. > > -Pieter > > On Tue, Oct 22, 2013 at 6:43 PM, Guillermo Lopez Taboada > wrote: > > > > Dear all, > > > > Torus Software Solutions (http://www.torusware.com) is a company that > > develops transparent replacements of TCP sockets. Currently two > > implementations are in our catalog: > >- Java Fast Sockets (JFS): a transparent replacement of JVM sockets, > > commercially available. > >- Universal Fast Sockets (UFS): a system sockets library, currently in > > beta. > > > > Both JFS and UFS accelerate transparently JeroMQ and ZeroMQ over TCP, > > respectively. The peformance benefit according to the benchmarks (see > below) > > is around 3 times faster communications both on loopback and InfiniBand. > > > > Both JFS and UFS operate at user-level, are easy to install and work > > immediately with existing ZeroMQ/JeroMQ setups, no recoding nor > modification > > of your ZeroMQ/JeroMQ installation is required. > > > > Is there anyone interested in trying out JFS/UFS? > > > > - JFS is available at http://torusware.com/nevonproducts/jfs/ > > - UFS is available only through our Early Adopters Program. Contact me > for > > further details. > > > > Please, feel free to let me know your thoughts about our products and > > approach. > > > > Best regards, > > > > Guillermo > > > > > > ## Machine spec ** > > > > > > 2 Dell PowerEdge R620x8 servers with: > > > > * Intel Sandy Bridge E5-2643 at 3.30GHz > > > > * 1600 DDR 32 GB > > > > * Mellanox ConnectX-3 VPI > > > > > > Software: > > > > * Red Hat Linux 6.2 (kernel 2.6.32-358) > > > > * OpenJDK 1.7 JVM > > > > * JeroMQ 3.0.0 > > > > * ZeroMQ 3.2.4 > > > > > > ## TCP Latency (Using 127.0.0.1) * > > > > > > ZeroMQ (C++) > > > > > >$ ./local_lat tcp://127.0.0.1:1234 100 (bind) > > > >$ ./remote_lat tcp://127.0.0.1:1234 100 (connect) > > > >message_size [b]10 100 1 k 10 k100 k > > > >avg_latency [us]14.225 15.284 16.007 26.961 46.865 > > > > > > ZeroMQ (C++) with UFS > > > > > >$ ./local_lat tcp://127.0.0.1:1234 100 (bind) > > > >$ ./remote_lat tcp://127.0.0.1:1234 100 (connect) > > > >message_size [b]10 100 1 k 10 k100 k > > > >avg_latency [us]4.492 4.764 5.064 7.796 17.602 > > > > > > JeroMQ > > > > > >$ java perf.LatencyServer 100 tcp://127.0.0.1:1234 > > (bind) > > > >$ java perf.LatencyClient 100 tcp://127.0.0.1:1234 (connect) > > > >message_size [b]10 100 1 k 10 k100 k > > > >avg_latency [us]18.910 19.001 19.956 37.553 85.696 > > > > > > JeroMQ with JFS > > > > > >$ java perf.LatencyServer 100 tcp://127.0.0.1:1234 > > (bind) > > > >$ java perf.LatencyClient 100 tcp://127.0.0.1:1234 (connect) > > > >message_size [b] 10 100 1 k 10 k100 k > > > >avg_latency [us] 3.396 3.304 4.202 7.614 31.765 > > > > > > > > > > ## InfiniBand Latency * > > > > > > ZeroMQ (c++) > > > > > >$ ./local_lat tcp://:1234 100 (bind) > > > >$ ./remote_lat tcp://:1234 100 (connect) > > > >message_size [b]10 100 1 k 10 k100 k > > > >avg_latency [us]17.401 17.905 19.321 31.185 76.595 > > > > > > ZeroMQ (c++) with UFS > > > > > >$ ./local_lat tcp://:1234 100 (bind) > > > >$ ./remote_lat tcp://:1234 100 (connect) > > > >message_size [b]10 100 1 k 10 k100 k > > > >avg_latency [us]11.918 11.678 13.978 23.637 72.325 > > > > > > JeroMQ > > > > > >$ java perf.LatencyServer 100 tcp://:1234 > > (bind) > > > >$ java perf.LatencyClient 100 tcp://:1234 (connect) > > > >message_
Re: [zeromq-dev] ZeroMQ Normal Socket Connectivity Issue
Hi Rashmi, If you're going to use ZMQ_STREAM for everything, the results will be clumsy compared to using PUB/SUB. Look in the tests/test_stream.cpp program for an example of how to send to a stream socket as client or server. -Pieter On Tue, Oct 22, 2013 at 7:17 PM, Rashmiranjan wrote: > Hi Team, > > I am developing one own message Queue where Queue can receive multiple > request from different publishers and will distribute to different > subscribers(host). i checked in the net and found ZeroMQ is the suitable > solution for my requirement. > > So I downloaded ZeoMQ 4.0.1 library and samples from the site and used the > sample application to test. By using ZMQ_STREAM my Queue is able to receive > the data from the normal socket but not able to send to normal socket. > > Kindly have any idea or any parameter need to set for the normal socket > connectivity. > > -- > Thanx and Regards > > *Rashmi...* > Cell: 9566080845 > > *Protect our environment, keep it safe; tomorrow, we’ll be saved!* > > > > > ___ > zeromq-dev mailing list > zeromq-dev@lists.zeromq.org > http://lists.zeromq.org/mailman/listinfo/zeromq-dev > > -- - Pieter Hintjens CEO of iMatix.com Founder of ZeroMQ community blog: http://hintjens.com ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] JeroMQ/ZeroMQ transparent acceleration with Fast Sockets
Hi Guillermo, Interesting stuff. Is UFS an add-on module on Linux that replaces standard sockets? It would be interesting if there was a free version available for people to test. I see the performance difference for C++ over Infiniband is about 30%. It would be useful to have figures for throughput, and also comparison of real TCP (not loopback) on normal sockets vs. UFS. -Pieter On Tue, Oct 22, 2013 at 6:43 PM, Guillermo Lopez Taboada wrote: > > Dear all, > > Torus Software Solutions (http://www.torusware.com) is a company that > develops transparent replacements of TCP sockets. Currently two > implementations are in our catalog: >- Java Fast Sockets (JFS): a transparent replacement of JVM sockets, > commercially available. >- Universal Fast Sockets (UFS): a system sockets library, currently in > beta. > > Both JFS and UFS accelerate transparently JeroMQ and ZeroMQ over TCP, > respectively. The peformance benefit according to the benchmarks (see below) > is around 3 times faster communications both on loopback and InfiniBand. > > Both JFS and UFS operate at user-level, are easy to install and work > immediately with existing ZeroMQ/JeroMQ setups, no recoding nor modification > of your ZeroMQ/JeroMQ installation is required. > > Is there anyone interested in trying out JFS/UFS? > > - JFS is available at http://torusware.com/nevonproducts/jfs/ > - UFS is available only through our Early Adopters Program. Contact me for > further details. > > Please, feel free to let me know your thoughts about our products and > approach. > > Best regards, > > Guillermo > > > ## Machine spec ** > > > 2 Dell PowerEdge R620x8 servers with: > > * Intel Sandy Bridge E5-2643 at 3.30GHz > > * 1600 DDR 32 GB > > * Mellanox ConnectX-3 VPI > > > Software: > > * Red Hat Linux 6.2 (kernel 2.6.32-358) > > * OpenJDK 1.7 JVM > > * JeroMQ 3.0.0 > > * ZeroMQ 3.2.4 > > > ## TCP Latency (Using 127.0.0.1) * > > > ZeroMQ (C++) > > >$ ./local_lat tcp://127.0.0.1:1234 100 (bind) > >$ ./remote_lat tcp://127.0.0.1:1234 100 (connect) > >message_size [b]10 100 1 k 10 k100 k > >avg_latency [us]14.225 15.284 16.007 26.961 46.865 > > > ZeroMQ (C++) with UFS > > >$ ./local_lat tcp://127.0.0.1:1234 100 (bind) > >$ ./remote_lat tcp://127.0.0.1:1234 100 (connect) > >message_size [b]10 100 1 k 10 k100 k > >avg_latency [us]4.492 4.764 5.064 7.796 17.602 > > > JeroMQ > > >$ java perf.LatencyServer 100 tcp://127.0.0.1:1234 > (bind) > >$ java perf.LatencyClient 100 tcp://127.0.0.1:1234 (connect) > >message_size [b]10 100 1 k 10 k100 k > >avg_latency [us]18.910 19.001 19.956 37.553 85.696 > > > JeroMQ with JFS > > >$ java perf.LatencyServer 100 tcp://127.0.0.1:1234 > (bind) > >$ java perf.LatencyClient 100 tcp://127.0.0.1:1234 (connect) > >message_size [b] 10 100 1 k 10 k100 k > >avg_latency [us] 3.396 3.304 4.202 7.614 31.765 > > > > > ## InfiniBand Latency * > > > ZeroMQ (c++) > > >$ ./local_lat tcp://:1234 100 (bind) > >$ ./remote_lat tcp://:1234 100 (connect) > >message_size [b]10 100 1 k 10 k100 k > >avg_latency [us]17.401 17.905 19.321 31.185 76.595 > > > ZeroMQ (c++) with UFS > > >$ ./local_lat tcp://:1234 100 (bind) > >$ ./remote_lat tcp://:1234 100 (connect) > >message_size [b]10 100 1 k 10 k100 k > >avg_latency [us]11.918 11.678 13.978 23.637 72.325 > > > JeroMQ > > >$ java perf.LatencyServer 100 tcp://:1234 > (bind) > >$ java perf.LatencyClient 100 tcp://:1234 (connect) > >message_size [b]10 100 1 k 10 k100 k > >avg_latency [us]22.415 24.222 25.270 40.103 114.448 > > > JeroMQ with JFS > > >$ java perf.LatencyServer 100 tcp://:1234 > (bind) > >$ java perf.LatencyClient 100 tcp://:1234 (connect) > >message_size [b] 10 100 1 k 10 k100 k > >avg_latency [us] 11.745 12.571 13.496 29.396 169,022 > > > ++ > > Guillermo > --- > Torus Software Solutions, CEO > Email: guillermo.lo...@torusware.com > WWW: http://www.torusware.com > > DISCLAIMER: > This message is intended exclusively for its addressee and may contain > information that is CONFIDENTIAL and protected by professional privilege. If > you are not the intended recipient you are hereby notified that any > dissemination, copy or disclosure of this communication is strictly > prohibited by law. If this message has been received in error, please > immediately notify us via e-mail and delete it. Thank you. > > ___ > zeromq-dev mailing list > zeromq-dev@lists.zeromq.org > http://li
[zeromq-dev] ZeroMQ Normal Socket Connectivity Issue
Hi Team, I am developing one own message Queue where Queue can receive multiple request from different publishers and will distribute to different subscribers(host). i checked in the net and found ZeroMQ is the suitable solution for my requirement. So I downloaded ZeoMQ 4.0.1 library and samples from the site and used the sample application to test. By using ZMQ_STREAM my Queue is able to receive the data from the normal socket but not able to send to normal socket. Kindly have any idea or any parameter need to set for the normal socket connectivity. -- Thanx and Regards *Rashmi...* Cell: 9566080845 *Protect our environment, keep it safe; tomorrow, we’ll be saved!* ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] what do I do bad with zmq_threadstart ?
On Wed, Oct 23, 2013 at 12:29 AM, Laurent Alebarde wrote: > Hi Devs, > > I am trying to use zmq_threadstart. My first test passing ctx as args > works, but I need now to pass two arguments. So I tried many ways and all > the time it ends with a compilor insult : > > error: invalid conversion from 'void (*)(void**)' to 'void (*)(void*)' > [-fpermissive] > In file included from ../tests/testutil.hpp:24:0, > from ../tests/test_concurrency_parano.cpp:20: > ../tests/../include/zmq_utils.h:94:18: error: initializing argument 1 of > 'void* zmq_threadstart(void (*)(void*), void*)' [-fpermissive] > make: *** [tests/test_concurrency_parano.o] Error 1 > > Hi, looking at the compiler output: is client_task defined as client_task (void **) ? The parameter should be void *. -- Mikko ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
[zeromq-dev] JeroMQ/ZeroMQ transparent acceleration with Fast Sockets
Dear all, Torus Software Solutions (http://www.torusware.com) is a company that develops transparent replacements of TCP sockets. Currently two implementations are in our catalog: - Java Fast Sockets (JFS): a transparent replacement of JVM sockets, commercially available. - Universal Fast Sockets (UFS): a system sockets library, currently in beta. Both JFS and UFS accelerate transparently JeroMQ and ZeroMQ over TCP, respectively. The peformance benefit according to the benchmarks (see below) is around 3 times faster communications both on loopback and InfiniBand. Both JFS and UFS operate at user-level, are easy to install and work immediately with existing ZeroMQ/JeroMQ setups, no recoding nor modification of your ZeroMQ/JeroMQ installation is required. Is there anyone interested in trying out JFS/UFS? - JFS is available at http://torusware.com/nevonproducts/jfs/ - UFS is available only through our Early Adopters Program. Contact me for further details. Please, feel free to let me know your thoughts about our products and approach. Best regards, Guillermo *## Machine spec *** 2 Dell PowerEdge R620x8 servers with: * Intel Sandy Bridge E5-2643 at 3.30GHz * 1600 DDR 32 GB * Mellanox ConnectX-3 VPI Software: * Red Hat Linux 6.2 (kernel 2.6.32-358) * OpenJDK 1.7 JVM * JeroMQ 3.0.0 * ZeroMQ 3.2.4 *## TCP Latency (Using 127.0.0.1) ** ZeroMQ (C++) $ ./local_lat tcp://127.0.0.1:1234 100 (bind) $ ./remote_lat tcp://127.0.0.1:1234 100 (connect) message_size [b]10 100 1 k 10 k100 k avg_latency [us]14.225 15.284 16.007 26.961 46.865 ZeroMQ (C++) with UFS $ ./local_lat tcp://127.0.0.1:1234 100 (bind) $ ./remote_lat tcp://127.0.0.1:1234 100 (connect) message_size [b]10 100 1 k 10 k100 k avg_latency [us]4.492 4.764 5.064 7.796 17.602 JeroMQ $ java perf.LatencyServer 100 tcp://127.0.0.1:1234(bind) $ java perf.LatencyClient 100 tcp://127.0.0.1:1234 (connect) message_size [b]10 100 1 k 10 k100 k avg_latency [us]18.910 19.001 19.956 37.553 85.696 JeroMQ with JFS $ java perf.LatencyServer 100 tcp://127.0.0.1:1234(bind) $ java perf.LatencyClient 100 tcp://127.0.0.1:1234 (connect) message_size [b] 10 100 1 k 10 k100 k avg_latency [us] 3.396 3.304 4.202 7.614 31.765 *## InfiniBand Latency ** ZeroMQ (c++) $ ./local_lat tcp://:1234 100 (bind) $ ./remote_lat tcp://:1234 100 (connect) message_size [b]10 100 1 k 10 k100 k avg_latency [us]17.401 17.905 19.321 31.185 76.595 ZeroMQ (c++) with UFS $ ./local_lat tcp://:1234 100 (bind) $ ./remote_lat tcp://:1234 100 (connect) message_size [b]10 100 1 k 10 k100 k avg_latency [us]11.918 11.678 13.978 23.637 72.325 JeroMQ $ java perf.LatencyServer 100 tcp://:1234 (bind) $ java perf.LatencyClient 100 tcp://:1234 (connect) message_size [b]10 100 1 k 10 k100 k avg_latency [us]22.415 24.222 25.270 40.103 114.448 JeroMQ with JFS $ java perf.LatencyServer 100 tcp://:1234 (bind) $ java perf.LatencyClient 100 tcp://:1234 (connect) message_size [b] 10 100 1 k 10 k100 k avg_latency [us] 11.745 12.571 13.496 29.396 169,022 ++ Guillermo --- Torus Software Solutions, CEO Email: guillermo.lo...@torusware.com WWW: http://www.torusware.com *DISCLAIMER: This message is intended exclusively for its addressee and may contain information that is CONFIDENTIAL and protected by professional privilege. If you are not the intended recipient you are hereby notified that any dissemination, copy or disclosure of this communication is strictly prohibited by law. If this message has been received in error, please immediately notify us via e-mail and delete it. Thank you.* ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] what do I do bad with zmq_threadstart ?
You have to cast the args to (void *) when calling zmq_threadstart,
and cast the void * argument back to void ** in the child thread.
On Tue, Oct 22, 2013 at 6:29 PM, Laurent Alebarde wrote:
> Hi Devs,
>
> I am trying to use zmq_threadstart. My first test passing ctx as args works,
> but I need now to pass two arguments. So I tried many ways and all the time
> it ends with a compilor insult :
>
> error: invalid conversion from 'void (*)(void**)' to 'void (*)(void*)'
> [-fpermissive]
> In file included from ../tests/testutil.hpp:24:0,
> from ../tests/test_concurrency_parano.cpp:20:
> ../tests/../include/zmq_utils.h:94:18: error: initializing argument 1 of
> 'void* zmq_threadstart(void (*)(void*), void*)' [-fpermissive]
> make: *** [tests/test_concurrency_parano.o] Error 1
>
> Here is my code exerpt :
>
> struct arg_t {
> void* ctx;
> uint8_t id[8];
> };
>
> for (int i = 0; i < QT_CLIENTS; i++)
> {
> arg_t* args = (arg_t*) malloc(sizeof (arg_t)); // it is up to the
> thread to free it
> args->ctx = ctx;
>
> int rc = build_test_stuff(i, args->id);
> assert (rc == 0);
>
> // start client thread with id
> threads[i] = zmq_threadstart (&client_task, args);
> }
>
> I read many posts on stackoverflow and elsewhere with the same problem with
> pthread_create, but it has not helped me.
>
> Any idea please ?
>
> Laurent
>
>
> ___
> zeromq-dev mailing list
> zeromq-dev@lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
--
-
Pieter Hintjens
CEO of iMatix.com
Founder of ZeroMQ community
blog: http://hintjens.com
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
[zeromq-dev] what do I do bad with zmq_threadstart ?
Hi Devs,
I am trying to use zmq_threadstart. My first test passing ctx as args
works, but I need now to pass two arguments. So I tried many ways and
all the time it ends with a compilor insult :
error: invalid conversion from 'void (*)(void**)' to 'void (*)(void*)'
[-fpermissive]
In file included from ../tests/testutil.hpp:24:0,
from ../tests/test_concurrency_parano.cpp:20:
../tests/../include/zmq_utils.h:94:18: error: initializing argument 1
of 'void* zmq_threadstart(void (*)(void*), void*)' [-fpermissive]
make: *** [tests/test_concurrency_parano.o] Error 1
Here is my code exerpt :
struct arg_t {
void* ctx;
uint8_t id[8];
};
for (int i = 0; i < QT_CLIENTS; i++)
{
arg_t* args = (arg_t*) malloc(sizeof (arg_t)); // it is up to
the thread to free it
args->ctx = ctx;
int rc = build_test_stuff(i, args->id);
assert (rc == 0);
// start client thread with id
threads[i] = zmq_threadstart (&client_task, args);
}
I read many posts on stackoverflow and elsewhere with the same problem
with pthread_create, but it has not helped me.
Any idea please ?
Laurent
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] Proposal for ZeroMQ certificate storage
You're right. No reason to store the key in clear even if it's broadcast in clear. On Tue, Oct 22, 2013 at 6:02 PM, Laurent Alebarde wrote: > I was considering only storage here, not broadcast. But what I propose > requires one additional operation to decrypt the key before broadcasting it. > I was not precise enough thought, sorry. > > The idea is that if some attacker gain control on the server, the public > keys stored are crypted. Catching plain text keys on the wire certainly > under TLS, or catching them in memory, makes the attacker work far harder. > > As a comparison, IMO, it is like storing clients personal data. The server > designer just crypt them because he wants to protect his customer's personal > data, whatever it is really useful or not. That's not the server designer's > role to judge that. His customer just expect he takes care of his data. > > > Le 22/10/2013 16:21, Pieter Hintjens a écrit : > > When you broadcast a public key for anonymous users to pick up, you > cannot encrypt it. > > > On Tue, Oct 22, 2013 at 2:25 PM, Laurent Alebarde > wrote: > > Hi Pieter, > > I have only one small comment inside "Use Cases": Why storing the public key > in plain text when it does not hurt to crypt it ? It is a question of > philosophy. One of my design principle for everything is to not degrade > performance, even when it looks not hurting, as far as it is cheap. > > Otherwise, what is below do not overlap and represents mainly some possible > answers to "What's missing here is some proposal for standard filenames and > certificate locations on disk. This should be part of a standard > specification, I think." > > Cheers, > > > Laurent > > > Le 22/10/2013 12:55, Pieter Hintjens a écrit : > > Did you have any comments on http://hintjens.com/blog:62? > > There's some overlap with your suggestions. > > On Tue, Oct 22, 2013 at 11:47 AM, Laurent Alebarde > wrote: > > Hi everybody, > > In addition to the format, a discussion about the storage of the > certificates may be usefull. > > I propose the following (I am very verbose so that I can understand myself > in one week ;-) ): > > Requirements: > > The certificates SHALL be able to be accessed in an efficient way using a > hash table or even an array. > For huge client base, a choice of databases, relational or nosql, SHOULD be > possible > The key that permit to retrieve the certificate SHALL be able to be > transmitted in plain text, without compromising security. Thus, the public > key SHALL not be considered as a valid key, even if many people consider the > public key can be public. Let's call it the "server's certificate storage > key" > The client key pair SHALL be able to be generated in the client or in the > server, at designer's choice. > The certificate on the server side SHALL contain at least the client public > key, but SHALL be able also to contain a server key pair dedicated to this > client. > The certificate on the client side shall contain the server's certificate > storage key. > > Rationals : > > Efficiency on the first step of the hand-check is a key against DDOS > attacks. > Database enables a good memory management and offers replications / > synchronisation. > The server's certificate storage key cab be sent in plain text by the client > in the HELLO message. When the server generates the certificate, its > server's certificate storage key can be a hash of a function of the > registration data of the client, or simply the client number, or whatever > appropriate to the designer. Then, the server's certificate storage key is > completely decorrelated from the cryptographic keys. The server's > certificate storage key is transmitted to the client along with the > certificate which contains the server public key. > The most secure is probably in the client ? > Having dedicated server keys per client is not so expensive, so let it be > possible for every one who wish it. > to enable the server to retrieve the appropriate certificate from its > storage > > Here is a possible scenario in the frame of a client registration under TLS > or equivalent: > > Both server and client generate a key pair. > The client transmit its public certificate to the server (only its public > key). > The server creates a certificate which contains its own key pair dedicated > to this client, and aggregates the client public certificate received. > The server generates an arbitrary key for this certificate, say a hash of > the two public keys, the clients organisation name and client number, and > checks it is unique - if not, add one until it is. This is the server's > certificate storage key. > The server transmit this key and its own public certificate to the client > which aggregates the information in a final certificate that contains the > client key pair, the server public key, and the certificate key. > > When the client sends HELLO to the server, it sends a modified HELLO that > contain the certificate key. With this key, the server retri
Re: [zeromq-dev] Proposal for ZeroMQ certificate storage
I was considering only storage here, not broadcast. But what I propose requires one additional operation to decrypt the key before broadcasting it. I was not precise enough thought, sorry. The idea is that if some attacker gain control on the server, the public keys stored are crypted. Catching plain text keys on the wire certainly under TLS, or catching them in memory, makes the attacker work far harder. As a comparison, IMO, it is like storing clients personal data. The server designer just crypt them because he wants to protect his customer's personal data, whatever it is really useful or not. That's not the server designer's role to judge that. His customer just expect he takes care of his data. Le 22/10/2013 16:21, Pieter Hintjens a écrit : When you broadcast a public key for anonymous users to pick up, you cannot encrypt it. On Tue, Oct 22, 2013 at 2:25 PM, Laurent Alebarde wrote: Hi Pieter, I have only one small comment inside "Use Cases": Why storing the public key in plain text when it does not hurt to crypt it ? It is a question of philosophy. One of my design principle for everything is to not degrade performance, even when it looks not hurting, as far as it is cheap. Otherwise, what is below do not overlap and represents mainly some possible answers to "What's missing here is some proposal for standard filenames and certificate locations on disk. This should be part of a standard specification, I think." Cheers, Laurent Le 22/10/2013 12:55, Pieter Hintjens a écrit : Did you have any comments on http://hintjens.com/blog:62? There's some overlap with your suggestions. On Tue, Oct 22, 2013 at 11:47 AM, Laurent Alebarde wrote: Hi everybody, In addition to the format, a discussion about the storage of the certificates may be usefull. I propose the following (I am very verbose so that I can understand myself in one week ;-) ): Requirements: The certificates SHALL be able to be accessed in an efficient way using a hash table or even an array. For huge client base, a choice of databases, relational or nosql, SHOULD be possible The key that permit to retrieve the certificate SHALL be able to be transmitted in plain text, without compromising security. Thus, the public key SHALL not be considered as a valid key, even if many people consider the public key can be public. Let's call it the "server's certificate storage key" The client key pair SHALL be able to be generated in the client or in the server, at designer's choice. The certificate on the server side SHALL contain at least the client public key, but SHALL be able also to contain a server key pair dedicated to this client. The certificate on the client side shall contain the server's certificate storage key. Rationals : Efficiency on the first step of the hand-check is a key against DDOS attacks. Database enables a good memory management and offers replications / synchronisation. The server's certificate storage key cab be sent in plain text by the client in the HELLO message. When the server generates the certificate, its server's certificate storage key can be a hash of a function of the registration data of the client, or simply the client number, or whatever appropriate to the designer. Then, the server's certificate storage key is completely decorrelated from the cryptographic keys. The server's certificate storage key is transmitted to the client along with the certificate which contains the server public key. The most secure is probably in the client ? Having dedicated server keys per client is not so expensive, so let it be possible for every one who wish it. to enable the server to retrieve the appropriate certificate from its storage Here is a possible scenario in the frame of a client registration under TLS or equivalent: Both server and client generate a key pair. The client transmit its public certificate to the server (only its public key). The server creates a certificate which contains its own key pair dedicated to this client, and aggregates the client public certificate received. The server generates an arbitrary key for this certificate, say a hash of the two public keys, the clients organisation name and client number, and checks it is unique - if not, add one until it is. This is the server's certificate storage key. The server transmit this key and its own public certificate to the client which aggregates the information in a final certificate that contains the client key pair, the server public key, and the certificate key. When the client sends HELLO to the server, it sends a modified HELLO that contain the certificate key. With this key, the server retrieve the appropriate certificate from an array, a map, or a database, and proceed with the hand-check. It is important to recall of course that I am not a security expert, nor a cryptography expert. It is just the expression of a system designer with performance, security and simplicity in mind. I may put that in a RFC if it is des
Re: [zeromq-dev] Proposal for ZeroMQ certificate storage
When you broadcast a public key for anonymous users to pick up, you cannot encrypt it. On Tue, Oct 22, 2013 at 2:25 PM, Laurent Alebarde wrote: > Hi Pieter, > > I have only one small comment inside "Use Cases": Why storing the public key > in plain text when it does not hurt to crypt it ? It is a question of > philosophy. One of my design principle for everything is to not degrade > performance, even when it looks not hurting, as far as it is cheap. > > Otherwise, what is below do not overlap and represents mainly some possible > answers to "What's missing here is some proposal for standard filenames and > certificate locations on disk. This should be part of a standard > specification, I think." > > Cheers, > > > Laurent > > > Le 22/10/2013 12:55, Pieter Hintjens a écrit : > > Did you have any comments on http://hintjens.com/blog:62? > > There's some overlap with your suggestions. > > On Tue, Oct 22, 2013 at 11:47 AM, Laurent Alebarde > wrote: > > Hi everybody, > > In addition to the format, a discussion about the storage of the > certificates may be usefull. > > I propose the following (I am very verbose so that I can understand myself > in one week ;-) ): > > Requirements: > > The certificates SHALL be able to be accessed in an efficient way using a > hash table or even an array. > For huge client base, a choice of databases, relational or nosql, SHOULD be > possible > The key that permit to retrieve the certificate SHALL be able to be > transmitted in plain text, without compromising security. Thus, the public > key SHALL not be considered as a valid key, even if many people consider the > public key can be public. Let's call it the "server's certificate storage > key" > The client key pair SHALL be able to be generated in the client or in the > server, at designer's choice. > The certificate on the server side SHALL contain at least the client public > key, but SHALL be able also to contain a server key pair dedicated to this > client. > The certificate on the client side shall contain the server's certificate > storage key. > > Rationals : > > Efficiency on the first step of the hand-check is a key against DDOS > attacks. > Database enables a good memory management and offers replications / > synchronisation. > The server's certificate storage key cab be sent in plain text by the client > in the HELLO message. When the server generates the certificate, its > server's certificate storage key can be a hash of a function of the > registration data of the client, or simply the client number, or whatever > appropriate to the designer. Then, the server's certificate storage key is > completely decorrelated from the cryptographic keys. The server's > certificate storage key is transmitted to the client along with the > certificate which contains the server public key. > The most secure is probably in the client ? > Having dedicated server keys per client is not so expensive, so let it be > possible for every one who wish it. > to enable the server to retrieve the appropriate certificate from its > storage > > Here is a possible scenario in the frame of a client registration under TLS > or equivalent: > > Both server and client generate a key pair. > The client transmit its public certificate to the server (only its public > key). > The server creates a certificate which contains its own key pair dedicated > to this client, and aggregates the client public certificate received. > The server generates an arbitrary key for this certificate, say a hash of > the two public keys, the clients organisation name and client number, and > checks it is unique - if not, add one until it is. This is the server's > certificate storage key. > The server transmit this key and its own public certificate to the client > which aggregates the information in a final certificate that contains the > client key pair, the server public key, and the certificate key. > > When the client sends HELLO to the server, it sends a modified HELLO that > contain the certificate key. With this key, the server retrieve the > appropriate certificate from an array, a map, or a database, and proceed > with the hand-check. > > It is important to recall of course that I am not a security expert, nor a > cryptography expert. It is just the expression of a system designer with > performance, security and simplicity in mind. > > I may put that in a RFC if it is desirable. > > Cheers, > > Laurent > > > > > > ___ > zeromq-dev mailing list > zeromq-dev@lists.zeromq.org > http://lists.zeromq.org/mailman/listinfo/zeromq-dev > > > > > > ___ > zeromq-dev mailing list > zeromq-dev@lists.zeromq.org > http://lists.zeromq.org/mailman/listinfo/zeromq-dev > -- - Pieter Hintjens CEO of iMatix.com Founder of ZeroMQ community blog: http://hintjens.com ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/m
[zeromq-dev] zeromq for arm9
Hi, I'm trying to develop an application for a small embedded computer Moxa IA240 with ARM9 CPU. There's an operating system Linux Moxa 2.6.9-uc0 #273 on board. I'm using a cross-compiler and I managed to cross-compile the zeromq library and copied the first client-server application from the tutorial. Unfortunatelly I'm getting errors such as: Error number:11, "Resource temporarily unavailable" during zmq_bind (function return 0 but zmq_errno is 11). I get this error also during zmq_connect and zmq_send. In addition, after the zmq_bind I can see the application listens on *:555, I can establish a TCP/IP socket connection with a terminal but message send/receive fails. Despite the errors I tried a lot of different binds: REQ/REP, PUB/SUB etc but nothing works.. What can be the problem? -- Grzegorz Brzezinski ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] Proposal for ZeroMQ certificate storage
Hi Pieter, I have only one small comment inside "Use Cases": Why storing the public key in plain text when it does not hurt to crypt it ? It is a question of philosophy. One of my design principle for everything is to not degrade performance, even when it looks not hurting, as far as it is cheap. Otherwise, what is below do not overlap and represents mainly some possible answers to "/What's missing here is some proposal for standard filenames and certificate locations on disk. This should be part of a standard specification, I think./" Cheers, Laurent Le 22/10/2013 12:55, Pieter Hintjens a écrit : Did you have any comments on http://hintjens.com/blog:62? There's some overlap with your suggestions. On Tue, Oct 22, 2013 at 11:47 AM, Laurent Alebarde wrote: Hi everybody, In addition to the format, a discussion about the storage of the certificates may be usefull. I propose the following (I am very verbose so that I can understand myself in one week ;-) ): Requirements: The certificates SHALL be able to be accessed in an efficient way using a hash table or even an array. For huge client base, a choice of databases, relational or nosql, SHOULD be possible The key that permit to retrieve the certificate SHALL be able to be transmitted in plain text, without compromising security. Thus, the public key SHALL not be considered as a valid key, even if many people consider the public key can be public. Let's call it the "server's certificate storage key" The client key pair SHALL be able to be generated in the client or in the server, at designer's choice. The certificate on the server side SHALL contain at least the client public key, but SHALL be able also to contain a server key pair dedicated to this client. The certificate on the client side shall contain the server's certificate storage key. Rationals : Efficiency on the first step of the hand-check is a key against DDOS attacks. Database enables a good memory management and offers replications / synchronisation. The server's certificate storage key cab be sent in plain text by the client in the HELLO message. When the server generates the certificate, its server's certificate storage key can be a hash of a function of the registration data of the client, or simply the client number, or whatever appropriate to the designer. Then, the server's certificate storage key is completely decorrelated from the cryptographic keys. The server's certificate storage key is transmitted to the client along with the certificate which contains the server public key. The most secure is probably in the client ? Having dedicated server keys per client is not so expensive, so let it be possible for every one who wish it. to enable the server to retrieve the appropriate certificate from its storage Here is a possible scenario in the frame of a client registration under TLS or equivalent: Both server and client generate a key pair. The client transmit its public certificate to the server (only its public key). The server creates a certificate which contains its own key pair dedicated to this client, and aggregates the client public certificate received. The server generates an arbitrary key for this certificate, say a hash of the two public keys, the clients organisation name and client number, and checks it is unique - if not, add one until it is. This is the server's certificate storage key. The server transmit this key and its own public certificate to the client which aggregates the information in a final certificate that contains the client key pair, the server public key, and the certificate key. When the client sends HELLO to the server, it sends a modified HELLO that contain the certificate key. With this key, the server retrieve the appropriate certificate from an array, a map, or a database, and proceed with the hand-check. It is important to recall of course that I am not a security expert, nor a cryptography expert. It is just the expression of a system designer with performance, security and simplicity in mind. I may put that in a RFC if it is desirable. Cheers, Laurent ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] Proposal for ZeroMQ certificate storage
Did you have any comments on http://hintjens.com/blog:62? There's some overlap with your suggestions. On Tue, Oct 22, 2013 at 11:47 AM, Laurent Alebarde wrote: > Hi everybody, > > In addition to the format, a discussion about the storage of the > certificates may be usefull. > > I propose the following (I am very verbose so that I can understand myself > in one week ;-) ): > > Requirements: > > The certificates SHALL be able to be accessed in an efficient way using a > hash table or even an array. > For huge client base, a choice of databases, relational or nosql, SHOULD be > possible > The key that permit to retrieve the certificate SHALL be able to be > transmitted in plain text, without compromising security. Thus, the public > key SHALL not be considered as a valid key, even if many people consider the > public key can be public. Let's call it the "server's certificate storage > key" > The client key pair SHALL be able to be generated in the client or in the > server, at designer's choice. > The certificate on the server side SHALL contain at least the client public > key, but SHALL be able also to contain a server key pair dedicated to this > client. > The certificate on the client side shall contain the server's certificate > storage key. > > Rationals : > > Efficiency on the first step of the hand-check is a key against DDOS > attacks. > Database enables a good memory management and offers replications / > synchronisation. > The server's certificate storage key cab be sent in plain text by the client > in the HELLO message. When the server generates the certificate, its > server's certificate storage key can be a hash of a function of the > registration data of the client, or simply the client number, or whatever > appropriate to the designer. Then, the server's certificate storage key is > completely decorrelated from the cryptographic keys. The server's > certificate storage key is transmitted to the client along with the > certificate which contains the server public key. > The most secure is probably in the client ? > Having dedicated server keys per client is not so expensive, so let it be > possible for every one who wish it. > to enable the server to retrieve the appropriate certificate from its > storage > > Here is a possible scenario in the frame of a client registration under TLS > or equivalent: > > Both server and client generate a key pair. > The client transmit its public certificate to the server (only its public > key). > The server creates a certificate which contains its own key pair dedicated > to this client, and aggregates the client public certificate received. > The server generates an arbitrary key for this certificate, say a hash of > the two public keys, the clients organisation name and client number, and > checks it is unique - if not, add one until it is. This is the server's > certificate storage key. > The server transmit this key and its own public certificate to the client > which aggregates the information in a final certificate that contains the > client key pair, the server public key, and the certificate key. > > When the client sends HELLO to the server, it sends a modified HELLO that > contain the certificate key. With this key, the server retrieve the > appropriate certificate from an array, a map, or a database, and proceed > with the hand-check. > > It is important to recall of course that I am not a security expert, nor a > cryptography expert. It is just the expression of a system designer with > performance, security and simplicity in mind. > > I may put that in a RFC if it is desirable. > > Cheers, > > Laurent > > > > > > ___ > zeromq-dev mailing list > zeromq-dev@lists.zeromq.org > http://lists.zeromq.org/mailman/listinfo/zeromq-dev > -- - Pieter Hintjens CEO of iMatix.com Founder of ZeroMQ community blog: http://hintjens.com ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
[zeromq-dev] Proposal for ZeroMQ certificate storage
Hi everybody, In addition to the format, a discussion about the storage of the certificates may be usefull. I propose the following (I am very verbose so that I can understand myself in one week ;-) ): Requirements: 1. The certificates SHALL be able to be accessed in an efficient way using a hash table or even an array. 2. For huge client base, a choice of databases, relational or nosql, SHOULD be possible 3. The key that permit to retrieve the certificate SHALL be able to be transmitted in plain text, without compromising security. Thus, the public key SHALL not be considered as a valid key, even if many people consider the public key can be public. Let's call it the "server's certificate storage key" 4. The client key pair SHALL be able to be generated in the client or in the server, at designer's choice. 5. The certificate on the server side SHALL contain at least the client public key, but SHALL be able also to contain a server key pair dedicated to this client. 6. The certificate on the client side shall contain the server's certificate storage key. Rationals : 1. Efficiency on the first step of the hand-check is a key against DDOS attacks. 2. Database enables a good memory management and offers replications / synchronisation. 3. The server's certificate storage key cab be sent in plain text by the client in the HELLO message. When the server generates the certificate, its server's certificate storage key can be a hash of a function of the registration data of the client, or simply the client number, or whatever appropriate to the designer. Then, the server's certificate storage key is completely decorrelated from the cryptographic keys. The server's certificate storage key is transmitted to the client along with the certificate which contains the server public key. 4. The most secure is probably in the client ? 5. Having dedicated server keys per client is not so expensive, so let it be possible for every one who wish it. 6. to enable the server to retrieve the appropriate certificate from its storage Here is a possible scenario in the frame of a client registration under TLS or equivalent: 1. Both server and client generate a key pair. 2. The client transmit its public certificate to the server (only its public key). 3. The server creates a certificate which contains its own key pair dedicated to this client, and aggregates the client public certificate received. 4. The server generates an arbitrary key for this certificate, say a hash of the two public keys, the clients organisation name and client number, and checks it is unique - if not, add one until it is. This is the server's certificate storage key. 5. The server transmit this key and its own public certificate to the client which aggregates the information in a final certificate that contains the client key pair, the server public key, and the certificate key. When the client sends HELLO to the server, it sends a modified HELLO that contain the certificate key. With this key, the server retrieve the appropriate certificate from an array, a map, or a database, and proceed with the hand-check. It is important to recall of course that I am not a security expert, nor a cryptography expert. It is just the expression of a system designer with performance, security and simplicity in mind. I may put that in a RFC if it is desirable. Cheers, Laurent ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] Question: ipc and multiple listeners
Good idea. I will. On 10/15/2013 3:45 AM, Pieter Hintjens wrote: > Hi Erik, > > It's a good question and not specified in the man page. Perhaps you'd > like to add something to doc/zmq_ipc.txt to make it clearer? > > -Pieter > > On Tue, Oct 15, 2013 at 3:11 AM, Erik Haller wrote: >> Can 1 zmq_socket (REP/ROUTER) serve one ipc:/// for >> multiple processes on Linux? Won't the input/output be spliced? >> >> It appears that it can. zeromq3 uses AF_UNIX, SOCK_STREAM as the ipc:// >> resource as defined in ipc_listener.cpp. Therefore, one zmq_socket can >> support multiple processes. >> >> ipc is such a general term. The documentation does not indicate the form >> of ipc. >> ___ >> zeromq-dev mailing list >> zeromq-dev@lists.zeromq.org >> http://lists.zeromq.org/mailman/listinfo/zeromq-dev > > ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
[zeromq-dev] jeromq in andorid
Why JEROMQ ANDROID machines in use can not receive messages sent PUB end of it,
my code is as follows:
Ctx ctx = ZMQ.zmq_init(1);
SocketBase sub = ZMQ.zmq_socket(ctx, ZMQ.ZMQ_SUB);
sub.setsockopt(ZMQ.ZMQ_SUBSCRIBE, "".getBytes());
sub.connect("tcp://192.168.119.100:18085");
while (true) {
Msg msg = sub.recv(0);
System.out.println(new String(msg.data()));
}___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
