On Sun, Jul 25, 2010 at 9:53 AM, Martin Sustrik <[email protected]> wrote:
> I suspect what you need is last-value cache. I.e. if you subscribe for > topic X you first get the latest known value of X, then catch up with > the stream of updates as usual. Right? The definition of "base state" depends on the use case, presumably. For market data, which consists of values for specific "instruments" (e.g. stocks), the base state is the last known price for an instrument. So when subscribing to a topic tree, you would want a snapshot of all instruments in that tree. For video, it's a key frame. The problem with doing this in-band is that it messes up delivery of current data, i.e. you'll get an arbitrary lag at startup. The problem doing this out-of-band is synchronization. For market data it's clear how to do that: you simply throw out snapshot data for which you've already received a more recent update, and keep what's left. For video data... how can you use an out of date keyframe? So as Martin says, different use cases have different solutions. I've no idea how you would synchronize video key frames with incoming frames, that does not seem to make sense. Added to all of this, the need to store data in the publisher, and explicitly ask the publisher to resend this snapshot. Which is why in most cases we've seen, applications don't do this: they simply wait for data to arrive. That strategy can be tuned at the publisher side by (re)sending data if needed to ensure any new subscriber will get a full data set within a certain time period. -Pieter _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
