[zeromq-dev] publish/subscribe and the "fast producer" problem

[Francesco]

Hi Andriy,

2017-03-05 20:13 GMT+01:00 Andriy Drozdyuk <drozzy at gmail.com>:
> If you block the pub when the sub hits their HWM, then it wouldn't be
> pub-sub anymore.
> The one positive property of pub-sub is that pub side never needs to worry
> about the subs. This allows you to scale... to a lot of subs.
> If you start placing at-least-once requirements on this, I suggest you don't
> use pub-sub, but instead design your own protocol.
> For example, all the queues like rabbitmq do this.
> I think this is what you actually want - because sounds like you're not
> willing to loose messages.
> At some point you *have* to decide to shed some load, and I find this
> article very nice:
> http://ferd.ca/queues-don-t-fix-overload.html

Thanks for the article, that's very nice indeed.

Generally speaking you're right. However I can argue that without the
"at-least-once" requirement we are in the following scenario: I'm
broadcasting a radio program at a speed where even the best radio
receiver model available on the market is unable to correctly receive
and decode the signal over the air. In such a scenario, for my
application, I prefer to have the broadcaster publish less information
(dropping it) so that at least 1 receiver is able to listen good music
rather than publishing everything and have nobody listen to what is
transmitted ...

Francesco