[zeromq-dev] PUB doesn't discard msg when no SUB
jia.li at credit-suisse.com
Thu May 26 22:37:05 CEST 2011
Perhaps a sockopt is the solution here?
My point is: if the socket, especially PUB/SUB, already decided to drop
some messages, then perhaps the decision on which message gets dropped
becomes an application-level decision? No matter which message you drop,
be it ancient or middle-aged, the truth is some message got dropped -
that implies the application would need to do some 'recovery' or
'sync-up' action (or maybe none at all!), where the application might
prefer either oldest or newest message.
From: Martin Sustrik [mailto:sustrik at 250bpm.com]
Sent: Thursday, May 26, 2011 4:08 PM
To: Li, Jia
Cc: ZeroMQ development list
Subject: Re: [zeromq-dev] PUB doesn't discard msg when no SUB
On 05/26/2011 09:49 PM, Li, Jia wrote:
> OR: with HWM in effect, do FIFO to kick out the oldest message in the
> waiting buffer.
The problem with that is that Internet, as is widely known, is a series
of tubes, meaning that there's a lot of tubes between the sender and the
receiver, the 0MQ tx queue being just first of them. Thus if we start
dropping oldest messages from the tx queue, we won't be actually
dropping oldest queued messages but rather middle-aged messages. (The
other tubes are TCP buffers, any intermediary devices, 0MQ queue on the
The only coherent solution for getting rid of outdated messages IMO are
the rate-controlled rolling buffers, similar to those used by PGM.
Please access the attached hyperlink for an important electronic communications disclaimer:
More information about the zeromq-dev