Ah I see. I will keep MPLv2 :) Thank you!
(see also discussions here:
https://mail.mozilla.org/pipermail/rust-dev/2014-July/010660.html )
Fantix
On Wed, Jul 2, 2014 at 6:42 PM, Pieter Hintjens wrote:
> Fantix,
>
> I'd recommend keeping the MPLv2 license, since otherwise you cannot
> merge pull
The queue will fill up in the background.
On Wed, Jul 2, 2014 at 9:33 PM, Martin Townsend
wrote:
> Hi Pieter,
>
> Thanks for the swift reply. I'll give it a go. Another quick question,
> the process could decide to do something else for minutes maybe even
> hours, would this upset the subscribe
I don't think it's about importance of different keys. The short nonce
works better as a counter, and 8 bytes is sufficient. The long nonce
could be a counter, but that's extra work to implement, and a *good*
random number generator is ideal. 16 bytes may be overkill, however
it's inherited from Cu
I've just remembered there are pollers other than epoll so this patch
will break them. I would be interested if the patch fixes Issue #795 so
I've cc'ed the author and if it does I'll fix up a patch that caters for
all pollers.
Best Regards,
Martin.
On 02/07/14 10:05, Martin Townsend wrote:
>
Hi Pieter,
Thanks for the swift reply. I'll give it a go. Another quick question,
the process could decide to do something else for minutes maybe even
hours, would this upset the subscriber or even the publisher or would it
just fill up it's receive queue? I just want to know whether it woul
Thanks a lot Pieter, I had missed that section.
I still miss the why somewhat though, is this purely to save computing
power as the transient keys are less important to protect then the
permanent keys ? And thus use shorter nonces.
On Wed, Jul 2, 2014 at 9:26 PM, Pieter Hintjens wrote:
> It say
It says, in the RFC: "We use two kinds of nonces in CurveZMQ. A long
nonce protects permanent keys, and is 16 octets from a good random
number generator. A short nonce protects transient keys and is an
8-octet sequential number."
http://rfc.zeromq.org/spec:26
On Wed, Jul 2, 2014 at 9:13 PM, Diego
My bad, I was not calling zmq_msg_init() on the destination message first,
so the internal call to close() was returning EINVAL.
Nothing to see here, move along.
On Wed, Jul 2, 2014 at 1:50 PM, Pieter Hintjens wrote:
> There's no good reason for it. If you like, make a patch and get it to
> wo
Hello all,
I've been reading up on the CurveZMQ and CurveCP specs.
I've noticed they use a mix if 8 and 16 bytes nonces, who are then all
passed to 24 bytes using a constant prefix.
I was wondering when 8 byte and when 16 byte nonces are chosen as well as
why.
Kind Regards,
Diego Duclos
Palm Sto
You can of course implement any code you like from the abstract model.
The one we use in C is based on the CZMQ style. I know it's not very
efficient, way too many memory allocations. The idea is, make it work,
then make it better.
On Wed, Jul 2, 2014 at 8:13 PM, Doron Somech wrote:
> Hi,
>
> I n
There's no good reason for it. If you like, make a patch and get it to
work as you'd expect.
On Wed, Jul 2, 2014 at 8:22 PM, Thomas Rodgers wrote:
> Just curious what the rationale for this is? The result of least
> astonishment (to me anyway) would be a copy of an empty message.
>
> zmq_msg_t a
Just curious what the rationale for this is? The result of least
astonishment (to me anyway) would be a copy of an empty message.
zmq_msg_t a;
zmq_msg_init(&a);
...
zmq_msg_t b;
int rc = zmq_msg_copy(&b, &a);
assert(rc == 0); // fails, errno=EINVAL
_
Hi,
I noticed that the codec class in ZProto is getting destroyed after each
send or receive, this means that the object cannot be reused and a lot of
heap allocations.
I don't see any constraints with reusing the object (all the fields already
copied to the needle buffer).
I'm writing a C# code
Simply empty the receive queues every time you read (do a non blocking
recv until there's no message), and keep the message that's most
useful to you (e.g. the latest one).
On Wed, Jul 2, 2014 at 6:11 PM, Martin Townsend
wrote:
> Hi,
>
> I want to use the pub/sub pattern for interprocess communic
I believe it's been mooted before, and ZMQ_STREAM sockets do this,
sending null messages to signal when there's a new client connection
and/or a disconnected client.
On Wed, Jul 2, 2014 at 2:08 PM, Goswin von Brederlow wrote:
> On Tue, Jul 01, 2014 at 06:23:41PM +0200, Pieter Hintjens wrote:
>> O
Hi,
I want to use the pub/sub pattern for interprocess communication.
Basically I have one application reading measurements and then posts it
to a number of other processes at a fixed rate of every 500 milliseconds.
One of the subscribing processes is only interested in reading every 2
seconds
Hi Quinlan,
Thanks for the suggestion. I has installed 32-bit in place of 64-bit and
built was fine.
Thanks,
Nayab Rasul.
On Wed, Jul 2, 2014 at 11:12 AM, Nayab Rasul wrote:
> Hi all,
>
> I was trying to write zeromq application for windows x86, I had installed
> 32 bit Release 4.0.4.
> I hav
On Tue, Jul 01, 2014 at 09:44:49PM -0500, Charles Remes wrote:
> Should take less than a second assuming a LAN or other low-latency network.
>
> cr
>
> On Jul 1, 2014, at 3:32 PM, Johnny Lee wrote:
>
> > Hello,
> >
> > I have a question about how fast an "average" workstation can subscribe t
On Tue, Jul 01, 2014 at 06:23:41PM +0200, Pieter Hintjens wrote:
> On Tue, Jul 1, 2014 at 4:46 PM, Goswin von Brederlow
> wrote:
>
> > 1) with ROUTER/DEALER I don't get a message when a subscriber
> > disconnects without unsubscribing.
> >
> > Eventualy the heartbeat will get it but that can tak
At a pinch, libzmq isn't respecting the RFC. However, the metadata is
extensible and adding a null identity property is allowed, even though
somewhat pointless. Your code has to parse the whole metadata and then
extract the properties you want to use.
-Pieter
On Wed, Jul 2, 2014 at 12:30 PM, Chri
Fantix,
I'd recommend keeping the MPLv2 license, since otherwise you cannot
merge pull requests without further clearance.
The problem is that a fork of an MIT-licensed repository will not
necessarily be MIT licensed. It's trivial to add code and relicense
the lot under a different license. Then,
I am playing around with ZMTP for 'reasons'. I have implemented my own ZMTP
client and I observe that when I connect to a ROUTER socket (which is a
simple CZMQ server) and progress through the greeting and NULL handshake,
the router is sending my client an identity property which I am not
expecting
Good day Nayab,
C# app or C++? I used to get those errors when linking to the wrong library;
i.e. 64 bit / 86 bit. Have you installed the x86 zmq libraries? If you’ve using
C#, are you using x86 clrzmq & x86 libzmq? DependencyWalker
(http://www.dependencywalker.com/) is of good help to check th
Thanks a lot! I'll take a look at CZMQ and libzmtp.
btw I may change the license to MIT :)
BR,
Fantix
--
http://about.me/fantix
On Wed, Jul 2, 2014 at 5:36 PM, Pieter Hintjens wrote:
> Very nice. The only comment I'd make is that the libzmq API is a
> little clunky and you might look at the
Very nice. The only comment I'd make is that the libzmq API is a
little clunky and you might look at the CZMQ zsock API as a model. The
code classes in CZMQ are zsock, zactor, and perhaps zbeacon and zmsg.
There's also an interesting API in libzmtp, which expresses separate
socket types as separate
I got bit by an interesting bug while learning to use czmq and zeromq.
If you're compiling on linux with gcc -std=c99 /AND/
you are including czmq.h /after/ stdint.h /and/
you are not defining /_BSD_SOURCE before/ stdint.h,
uint is not properly defined, causing a build error in
zrex.h ...
This p
Hi all,
I was trying to write zeromq application for windows x86, I had installed
32 bit Release 4.0.4.
I have added include folder and lib folder and lib file to project.
I am using window 64 -bit windows 7 machine with Visual studio 2010 for
development.
I was getting compilation errors like be
After stopping the IO threads wait for the associated poller to stop
before destroying them to avoid get_load () == 0 assertion.
Potentially a fix for Issue #795
---
src/ctx.cpp | 12 ++--
src/epoll.cpp | 20 +++-
src/epoll.hpp | 4
src/io_thread.c
Hi Trevor,
here is the pull request for the issue mentioned above:
https://github.com/zeromq/jzmq/pull/330
I have one more question regarding recvByteBuffer method: in c++ code I
noticed that in case you receive more data than it is available in provided
buffer, you return truncated number of byt
29 matches
Mail list logo
