[zeromq-dev] max PUB/SUB topics

[Brian T. Carcich]

On Wed, May 15, 2019 at 8:40 AM Bekritsky, Benjamin via zeromq-dev <
zeromq-dev at lists.zeromq.org> wrote:

> Turns out Justin’s original suggestion to “to set SNDHWM=0 on the SUB
> socket and RCVHWM=0 on the PUB socket” resolves the issue. In particular on
> the SUB socket.  I had mistakenly set the *RCV*HWM for the SUB socket.
>


On Wed, May 15, 2019 at 6:23 AM James Harvey <jamesdillonharvey at gmail.com>
wrote:

> [...]
>
1. subscriptions make it through to the publisher, this is where the
> filtering happens (apart from pgm/mcast transport)
>


Thank you/aHA/Eureka/the light just came on:  each setsockopt/ZMQ_SUBSCRIBE
by the subscriber ***S*e*ND*s** a message **to** the publisher, which is
why the subscriber needs to set *SND*HWM to 0 (I suppose anything over
65535 woould work for 16-bit topics).

I updated my example code
<https://github.com/drbitboy/test_0mq_subscribe_limit>, and it now works as
expected.



Philosophical sidebar:  why does it seem that we always end up in the
internals?  Stated another way, why doesn't the library just work all the
time for every case  (Although if it did, wouldn't many of us be out of a
job;-)?

#1 I am not saying anything against 0MQ; on the contrary, I think it's
amazing.

I guess the answer is the Pareto Principle (80/20), i.e. that any single
library cannot handle all edge cases with its default settings, so we spend
80% of our time, digging into the internals, for the 20% that are edge
cases.

For example, the default HWMs of 1000 are not unreasonable; they work fine
until a case like Benjy's comes along,  Then, to solve his problem we
needed those (Justin, James) who understand the internals to provide the
answer.  Maybe the default HWM should be zero (i.e. infinite; damn the
torpedoes, full speed ahead!;-), and let developers who need finite HWMs
set them up themselves*. Then we'd be fine (until the next edge case;-).

* sort of like how I got into the habit of putting [IMPLICITNONE] at the
start of every FORTRAN module.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20190515/2a1f03ef/attachment.htm>