Re: Fast SCP
Jean-Marie Sulmont / RTS <>
31 Jul 2008 5:34AM ETCheers for this David -- that was *very* useful.
I agree with the fact that as the technology matures, FAST actors will move towards more dynamic templates "diffusion".
I like even more the fact that templates might even be generated on the fly, for the lifetime of a session!!
Yet when this is the case, there is going to be situations where a message encoded in T_(i+1) is received by an decoding agent before receiving template T_i.
It might be nice that SCP provides with similar guaranties, i.e., without specifying a template dissemination protocol, yet provides its users with some sort of consistency guaranties.
And I agree that SCP and encoding/decoding are orthogonal matters beyond the fact that encoding and decoding are based on a template ID -- whatever that template id means.
That's something I'm interested in and have some experience from past jobs :)
> The change rate of templates is very much application dependent. Some
> applications will have templates as static as the application protocol
> they are encoding. Otheres will change once a month or every other week.
> Yet others will change templates midstream to gain higher performance
> (better compression and/or lower latency) or to minimize manual
> administration and deployment overhead.
>
> Since FAST is fairly new and SCP even newer, it is likely that early
> implementations will lean to the static side. However, as the technology
> matures and more implementations become available, the opportunities to
> use the dynamic features of SCP increases.
>
> FAST actually says nothing about templates being common knowledge. The
> only thing it says is that a template must be known to the decoder
> before it decodes the first instance of that template. Templates may
> very well be short lived creatures, even generated on the fly, and only
> used in a single session between two peers.
>
> In addition to defining the actual messages to encode templates, SCP
> also defines template interchange for stream oriented scenarios with
> reliable delivery (think TCP). Though, you're correct in that it doesn't
> define a template exchange model for unreliable, datagram oriented
> transports (think UDP). The reason is that multicast applications
> present a number of implementation strategies where none is superior in
> general. Different types of applications may have different types of
> optimal template interchange schemes.
>
> There are challenges in multicast template distribution but they are not
> harder to solve than the similar challenges you have for the application
> data you intend to distribute.
>
> And in the long run, I'd rather have the software solve the template
> synchronization problem for me than relying on manual intervention, e.g.
> perodically check for new templates on some web site and make sure I run
> on the latest and greatest.
>
> /David
>
> >
> > >
> > > I thinking of using Fast SCP 1.1 but I also would like to avoid
> > > sending the same template information over the network too often.
> > >
> > Hi Dimitri
> >
> > What do you call too often?
> >
> > I would think that templates are fairly static objects. Think about
> > what would occur if templates were broadcast on the fly? There would
> > be syncronization problems hard to solve, such as a distributed
> > consensus, or atomic broadcast (total order).
> >
> > For FAST assumes the current set of templates is *common knowledge*
> > that is, everybody knows the set of templates, and everybody knows
> > that everybody knows the set of templates, and so forth.
> >
> > I doubt that SCP is handling this problems, hence, there must be a
> > priori rules for changing current set of templates.
> >
> > You should not worry about update frequencies.
