On Wed, 2016-05-04 at 05:46 +0200, Michal Vyskocil wrote:
> Hi,
>
> Just for a curiosity - the content of packaging/debian collide with
> standard Debian packaging? It is intentionally there to not clash, so maybe
> solve this problem. Either by not generating them, either by defying safer
> locat
Thanks for the clarification.
On Tue, May 3, 2016 at 2:51 PM Michal Vyskocil
wrote:
> Hi,
>
> There is nothing like that in malamute broker as far as I know.
>
> You would need to design a custom protocol between client and service to
> do so.
> Dne 3. 5. 2016 8:04 PM napsal uživatel "Osiris Pe
Just to clarify, in the Malamute selftest, there is this code:
```
mlm_client_set_producer (writer1, "weather");
mlm_client_set_producer (writer2, "traffic");
mlm_client_set_consumer (reader1, "weather", "newyork");
mlm_client_set_consumer (reader1, "traffic", "newyork");
mlm_cl
Dear ZeroMQ community,
I wonder if ZeroMQ, especially using the ipc protocol, can be considered
light-weight, and how this can be motivated/proven.
An important point is of course what defines light-weight. I could just run
the performance tests, but that would just give me numbers of which I don
I use ZeroMQ in Windows environment.
This past week I ran Memory Validator on zeromq and I was surprised with a
hot spot of memory allocation.
MV show that there is a 1Mb allocation happening over and over for every
message read.
This was done to fix https://github.com/zeromq/libzmq/issues/1608.
Yes, that's it. One client can produce only on one stream, while it can
consume more.
Dne 4. 5. 2016 1:06 PM napsal uživatel "Osiris Pedroso" :
> Just to clarify, in the Malamute selftest, there is this code:
> ```
> mlm_client_set_producer (writer1, "weather");
> mlm_client_set_producer (
If you want a lightweight ZeroMQ client library that supports IPC on
Linux, look at libzmtp. It is 1.3K lines of code with no dependencies.
https://github.com/zeromq/libzmtp
On Wed, May 4, 2016 at 1:21 PM, Osiris Pedroso wrote:
> I use ZeroMQ in Windows environment.
>
> This past week I ran Memo
My contribution to this project ends next week, as it was for my
graduation, so I don't think this is the right time to switch IPC backends
;-) This question came up while working on my report, when I wanted to
write something about using a light-weight library, when I realized I had
no idea what t
Hi,
My incoming messages to stream socket are being split in < 8kB parts, while
I don't have any framing denomination on the ZeroMQ side. As I understand,
this is down to OS TCP sockets implementation cuting them to some MTU size,
but I don't see it. If I do tcpdump on my channel, I am seeing 20kB
It is hard coded in the libzmq, you can change it and recompile, change
in_batch_size in config.hpp.
If you really want to you can make a socket option to change it, maybe
called ZMQ_STREAM_BUFFER_SIZE.
If you do make a new socket option, you want to give it to the raw_decoder
in stream_engine.cpp
But more important when implementing a stream engine you cannot rely on
receiving the entire message, this is important, if you send block of 20K
the receiving side OS can decide to split it into 20 1k messages.
So my suggestion, don't change anything, process 8KB buffer call receive
again and pro
IMO, it seems worth having this option when the OS takes advantage of it.
On Wed, May 4, 2016 at 9:25 AM Doron Somech wrote:
> But more important when implementing a stream engine you cannot rely on
> receiving the entire message, this is important, if you send block of 20K
> the receiving side
Hi all,
I was writing a summary article on community building and revisited
the C4 RFC. There were many small things that were out of date,
speculative, or did not fit with our current best practice.
So I've updated it here: https://github.com/zeromq/rfc/pull/83
Please *do* read the diffs and le
OK, I'm going to answer my own (stupid) question.
- RFC 22 will be deprecated
- RFC 42 is the new version of C4 (revision 3)
- I'll stop using the cute form "C4.1"
So we can instead look at RFC42 and check that it's accurate.
-Pieter
On Thu, May 5, 2016 at 8:52 AM, Pieter Hintjens wrote:
> Hi
14 matches
Mail list logo
