[zeromq-dev] Formally modelling the publish-subscribe pattern

John Lång john.lang at mykolab.com
Tue Nov 3 16:57:41 CET 2020


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.lang at 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 at lists.zeromq.org
> https://lists.zeromq.org/mailman/listinfo/zeromq-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20201103/d5a88828/attachment.htm>


More information about the zeromq-dev mailing list