Ironically, in my testing of high message rate), allowing multipart
creates significant costs. Multipart is just one way of getting
zero-copy, and even then only works on writing, not reading.
For high performance brokers like Malamute I'd *really* like to be
moving blobs around instead of lists o
M> Perhaps it is because I spend my days in a higher level language
M> like Python, but zproto is not an attractive option.
Same here. I will read in detail about it shortly, but it may not make
it into my toolbox as a multipart replacement. Multipart looked very
cool when I found 0MQ, but I've en
I like the idea of using ZAP as a test case. It's using multipart now
and that does indeed work well.
On Wed, Feb 4, 2015 at 12:35 AM, Gregg Irwin wrote:
> AK> So *maybe* a documentation effort is what is needed to better
> AK> explain those thing.
>
> The guide explains things in great detail, a
AK> So *maybe* a documentation effort is what is needed to better
AK> explain those thing.
The guide explains things in great detail, and an engaging manner. How
do you improve on it, aside from removing the things that need
explaining?
-- Gregg
___
ze
Hello,
I believe it's not enough. Well, your tests seem to prove it's not enough.
My guess would be that the socket is indeed connected, but the
subscriptions have not yet been sent (or acknowledged by the
publisher). I may be wrong here, I don't know much
about the ZMTP protocol.
What you could
On Tue, Feb 3, 2015 at 2:04 PM, Pieter Hintjens wrote:
> Thanks for the questions. I'd try to flatter by saying how great these
> questions are, except I know you're all way too smart to fall for
> that. :)
>
> Let me answer a bunch of questions in one go:
>
> * Sorry for not posting this here. I
@Doron: Yes I like multi part because its a very simple way build
"multiple-fields message". I once considered using protobuff + raw
socket for a pet project of mine, and I ended using ZMQ framing
because it was simpler.
The problem if we pick an other serialization solution is that it
needs to bui
On Tue, Feb 3, 2015 at 11:27 PM, Thomas Rodgers wrote:
>> * Sessions require protocol commands that are invisible to "normal"
>> use. That means either protocol support (e.g. command frames) or some
>> layering on top of ZeroMQ blobs.
For sure, command frames are designed for this and that's wha
>
> * Sessions require protocol commands that are invisible to "normal"
> use. That means either protocol support (e.g. command frames) or some
> layering on top of ZeroMQ blobs.
What would the argument be for not just using command frames for this?
On Tue, Feb 3, 2015 at 4:04 PM, Pieter Hintjen
Thanks for the questions. I'd try to flatter by saying how great these
questions are, except I know you're all way too smart to fall for
that. :)
Let me answer a bunch of questions in one go:
* Sorry for not posting this here. I've written a more detailed
analysis of the motivation for this threa
The thing is that you like multi-part because it simple serialization tool
and not because mutli access to socket,
I think that removing mutli-part doesn't necessary mean removing
serialization solution.
For java and .Net we can use fluent api for sending:
Message.New().AddString("Hello").AddStr
The single biggest problem I see people having in the JVM community is
their lack of understanding of the concurrency model. I haven't had
time to internalize the proposal just yet but if it helps people write
better/simpler software, I'm all for it.
-Trev
On Tue, Feb 3, 2015 at 4:33 PM, frank w
Hi,
Please excuse for writing this on my phone
I do not see any usecase nor detailed motivation what the problem is that
causes this somewhat fundamental proposal.
I think this approach is somewhat surprising and against the C4 thing. Not sure
if this is a problem or not, but there is a l
On Tue, Feb 3, 2015 at 7:00 AM, drebs wrote:
Thanks a lot for your answer, now it works like a charm.
>
> I couldn't find documentation about this, do you think it's a good idea to
> add
> a paragraph to zmqstream.send docstring (or anywhere else) about threaded
> use?
>
> If you think it's a goo
I happily use multipart rather a lot, to the point that I recommend that
pyzmq users exclusively use send/recv_multipart, and never single-frame
send/recv. I think it enables a really nice API. I find it very useful to
be able to send a large buffer plus a header of message information without
havi
Hi,
I'm dealing with the pub-sub "slow joiner" problem. As I understand it,
the problem arises, in part, because connections are asynchronous and
zmq_connect() returns before the connection is actually established.
I hooked up a monitor and wait until the monitor indicates the socket is
in the C
Seems to only happen if the XPUB connects rather than binds. Is this
intended behavior?
The problem is that if I restart the process on the other side (with a
SUB socket), then XPUB never clears the subscription, and so the
publisher could accumulate lots of old subscriptions over time.
Justin
__
Hello everyone,
I have read this thread and the blog post from Pieter.
I am looking forward to some of those things, but I have some reserve
about other points. I'll try to explain what I think, and why.
I agree that ZMQ_IDENTITY is a bit confusing. Allowing remote client
to set routing informati
Thanks a lot for your answer, now it works like a charm.
I couldn't find documentation about this, do you think it's a good idea to add
a paragraph to zmqstream.send docstring (or anywhere else) about threaded use?
If you think it's a good idea, I have a suggestion based on the info you gave
me.
I'm not sure if I like having picture as a libzmq level thing.
It really only makes sense for C language bindings in my book. most other
bindings use their own serialization mechanisms.
On Tue, Feb 3, 2015 at 2:06 PM, Pieter Hintjens wrote:
> On Tue, Feb 3, 2015 at 1:01 PM, Doron Somech wrote:
I agree that the best place for session management is at the transport.
However implementing the session management at the server socket level
should be pretty simple, even as POC. Only issue is how to make sure user
is not sending the same messages as the socket sending, but we might ignore
the pr
On Tue, Feb 3, 2015 at 1:01 PM, Doron Somech wrote:
> Pieter - regarding the blog post, I'm not sure about setting the routing id
> on the socket
Indeed, that isn't atomic with sending and so can't work with
threadsafe sockets. I've changed the article.
I think we can either get the routing id
Pieter - regarding the blog post, I'm not sure about setting the routing id
on the socket, the problem is that it's not thread safe (2 calls to the
socket) and could lead to complexity, we can use the thread local storage
for the routing id but I think it is still complicated.
Why not have it as p
There has been a zmq_sendiov/recviov call for ages, undocumented and
rarely used. This would indeed be a good alternative to multipart for
the zerocopy use case.
On Mon, Feb 2, 2015 at 10:59 PM, Maurice Barnum wrote:
> Is there any thought to adding a writev() analogue like zmq_msg_sendv()?
>
> O
I've written up my understanding of this thread: http://hintjens.com/blog:84
Thread safety would solve the perennial problem of sending data via
ZeroMQ, from short-lived threads. Performance in many cases would go
up, not down. We see way too many apps that create/connect a socket
for every messag
Can I ask why people think thread safety around sockets is in any way
important? or even beneficial at all if it impacts performance negatively?
Most libraries I've found aren't thread safe because it's cheaper to be
that way and let the application handle any concurrency in a sensible way
for what
26 matches
Mail list logo
