[zeromq-dev] ØMQ 2.1.0 beta release archive

[Steven McCoy]

On 6 December 2010 19:33, Martin Sustrik <sustrik at imatix.com> wrote:

> That doesn't work with high speed feeds constantly publishing.  The only
>> workaround that springs to mind is to allow access to the queue length
>> for the connected transports, like a ioctlsocket (FIONREAD) or ioctl
>> (SIOCOUTQ).  Then the application can perform, at least, coarse rate
>> limiting on the queue depth.
>>
>
> That's just shifting the problem to the application, not solving it. What
> will the application do when 0MQ signals that it can't accept more messages?
> Hm. Store them on disk? But if so, why not simply set ZMQ_SWAP. Etc.
>
> The real problem here is that there's more data to process than the
> hardware can accommodate. There's no way to solve that on either 0MQ or
> application level. "Buy more/better hardware" seems to be the only
> reasonable advice.
>
>
It is entirely dependent upon the application domain.  If it were market
data a reasonable option is to store and conflate updates until the
downstream channel capacity is available.  If you were re-implementing
REQ/REP over multicast you may desire back pressure in order to report
status back upstream.

I'm out of plausible cases.

-- 
Steve-o
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20101206/5145f016/attachment.htm>