Hi Brett,
Thanks for your answer! It clarified many points for me.
Cheers,
John
Brett Viren via zeromq-dev kirjoitti 3.11.2020 klo 17.20:
Hi John,
John Lång <john.l...@mykolab.com> writes:
the large messages are in the order of 12 megabytes
In my limited experience over LANs this is not so overly large to
warrant any special treatment.
The small messages either contain payload data or the size of the next
large message
ZeroMQ messages carry their size. Unless maybe you are trying to enact
some kind of zero-copy you may not need to pre-send an explicit "large
message" size. (also in my experience zero copy is only useful if
pushing maximum possible throughput, and if that's the goal, there
are many gotcha's)
I just like to point out that I'm indeed interested in maximising
throughput, or even better trying to keep it stable and predictable.
Zero-copy would be ideal for me. By the way, does 0MQ support something
like this Remote Direct Memory Access (RDMA) protocol for transport? I
think that anything using the OS for handling TCP/IP can't be truly
zero-copy.
How do I get the size of the message? I'm currently using the version of
0MQ I got from Debian repositories, which I think is libzmq, though I'm
having trouble for finding the API documentation for C++. I guess
documentation for C is good enough. I'm using the following function (I
copied the declaration straight from <zmq.hpp>) for receiving the
messages and it asks for the size of the buffer argument:
inline size_t recv (void *buf_, size_t len_, int flags_ = 0)
This is why I send the size of the large message as a small message, so
that I can call realloc on buf with len and then pass the pointer to 0MQ.
The problem is this: What happens if process A sends the small message
containing the size of the large message to process B, but before B
has received this message, A already begins sending the large message.
The large message will exist in the sender queue, then its data is
transported, then the message resides in the receiver queue. From the
two endpoint applications point of view the message is sent atomically.
Is it possible that the high water mark is
exceeded and thus the large message gets dropped?
HWM is in units of message count, not bytes. HWM will be reached when
the number of queued messages get large enough.
Whether subsequent messages are dropped or whether the socket blocks
depends on socket type and socket options.
As of message sizes and HWM, I'm asking these questions because I'm
trying to consider all possible scenarios instead of just the likely
ones. I'm using PUB-SUB and it was established earlier in this thread
that the publisher will start dropping messages in case the HWM is
exceeded. It's good news for me though that HWM is in messages and not
bytes. Is it possible to check in advance that there will be room for
sending at least two messages?
How about if A continues sending new unrelated small messages and
there happens to be enough space for them in the queue? Do these
messages get through to B?
As long as HWM is not reached there is nothing to impede subsequent
messages.
-Brett.
_______________________________________________
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
https://lists.zeromq.org/mailman/listinfo/zeromq-dev
_______________________________________________
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
https://lists.zeromq.org/mailman/listinfo/zeromq-dev
