I love this proposal! 😍
> On 28 Oct 2016, at 19:56, Luca Boccassi wrote:
>
> Hello all,
>
> Since we are hopefully close to release libzmq 4.2, I checked what's the
> API/ABI status in CZMQ master vs 3.0.2. There are a _lot_ of ABI
> breakages, and a couple of API too.
>
> Given it's been now
Just my 5 cents: AFAIK the RADIO/DISH sockets are the newer, thread-safe
sockets, which don't support multi part messages (ZMQ_SNDMORE option is not
accepted).
On 29 Aug 2017, at 14:35, Stephan Opfer wrote:
>> Note that multi-part does _not_ imply contiguous memory location on the
>> receive
I'm just curious, how large are those sensor values, how many do you keep
around, and to how many other robots do you intend to send them?
Could it be premature optimization? Just asking because maybe it's not worth
the extra effort to make it zero-copy. Just copy and pass ownership to ZMQ.
Reg
Just dropping in here. ZMQ does exactly that: It takes and delivers byte arrays
("blobs"). 300,000 times 3 floats should not be a problem. ZMQ allows messages
of multiple gigabytes, as far as I know. Whether the latency will be small
enough for you, you'll have to try and measure.
Best regards
Hi
WARNING: I’m no infosec expert.
I’m just thinking out loud, so please bear with me. To my understanding, the
keys used by the crypto primitives (NaCl/TweetNaCl) used in CurveZMQ are just
32 secret bytes. You already have about 2000 secrets for those 2000 identities,
their current format jus
Hi
Not sure why Justin suggested using a ROUTER-Socket on each side.
I think having the A node bind a ROUTER socket and each B node connect using a
DEALER socket is enough. One single TCP port would have to be bound. The ROUTER
socket on the A node is needed to distinguish between the differen
