|
FAST Protocol
< Previous Next >
Re: Fast SCP
David Rosenborg / Pantor Engineering AB
1 Aug 2008 10:16AM ETI'm not sure I understand. What do you mean by optional? Optional per message or optional per application? If you mean per message, how do you discover the absence of a length preamble on a particular message?
/David
> As I mentioned earlier, an optional length prefix to the message
> would easily ensure message separation without the block stuff. Would
> it be simpler?
>
> Greg.
>
> > Yes, it would work in some situations, but it requires you to
> > use blocks in general which might not be desired. Furthermore,
> > you'd have to restrict a block to contain exactly one message
> > (at least in situations where you know you're using extended
> > templates (as percieved by the receiver, which might not always
> > be possible to know)).
> >
> > Also, the constraint list would have to be extended to prohibit the
> > bytes that constitute the extension from looking like the start of a
> > message, which is rather tricky in the general case. It's probably
> > solvable by always adding two pad bytes at the start of the extension
> > the first always having the value 0xc0, and the second having the
> > value of some unused tid.
> >
> > This last constraint is not necessary if you enforce the one message
> > per block constraint for all messages. But if a decoder make use of
> > this constraint it will suddenly behave in a non standard way.
> >
> > /David
> >
> >
> > > I think the easiest approach is to create a FAST best practices
> > > guide that includes instructions for achieving support for multiple
> > > message template versions at the same time. Summarizing what has
> > > been said before, this would require:
> > >
> > > 1) Length prefixed blocks
> > > 2) Fields cannot be added to sequences
> > > 3) Fields can only be added to a group if the group is the last
> > > field instruction in a template and the added fields do not
> > > affect the groups use of a presence map (e.g. a group that does
> > > not need a presence map can only have fields added that don't
> > > require entries in the presence map).
> > > 4) New fields cannot use operators that would affect shared
> > > dictionary values.
> > >
> > > Jake
> > >
Fast SCP Dimitry London / Morgan Stanley 30 Jul 2008 10:16PM ET Re: Fast SCP David Rosenborg / Pantor Engineering AB 31 Jul 2008 3:28AM ET Re: Fast SCP Rolf Andersson / Pantor Engineering 31 Jul 2008 6:17AM ET Re: Fast SCP Rolf Andersson / Pantor Engineering 31 Jul 2008 9:05AM ET Re: Fast SCP Hanno Klein / Deutsche Börse Systems 31 Jul 2008 10:06AM ET Re: Fast SCP Rolf Andersson / Pantor Engineering 31 Jul 2008 10:15AM ET Re: Fast SCP Greg Orsini / Cameron Systems 31 Jul 2008 11:44AM ET Re: Fast SCP Rolf Andersson / Pantor Engineering 1 Aug 2008 2:06AM ET Re: Fast SCP Rolf Andersson / Pantor Engineering 1 Aug 2008 2:39AM ET Re: Fast SCP Rolf Andersson / Pantor Engineering 1 Aug 2008 3:13AM ET Re: Fast SCP Hanno Klein / Deutsche Börse Systems 1 Aug 2008 3:33AM ET Re: Fast SCP Rolf Andersson / Pantor Engineering 1 Aug 2008 3:57AM ET Re: Fast SCP Rolf Andersson / Pantor Engineering 1 Aug 2008 4:10AM ET Re: Fast SCP Rolf Andersson / Pantor Engineering 1 Aug 2008 3:06AM ET Re: Fast SCP David Rosenborg / Pantor Engineering AB 1 Aug 2008 6:28AM ET Re: Fast SCP Jacob Northey / The LaSalle Technology Group 1 Aug 2008 8:21AM ET Re: Fast SCP David Rosenborg / Pantor Engineering AB 1 Aug 2008 9:33AM ET Re: Fast SCP Greg Orsini / Cameron Systems 1 Aug 2008 10:01AM ET Re: Fast SCP
David Rosenborg / Pantor Engineering AB 1 Aug 2008 10:16AM ET Re: Fast SCP Greg Orsini / Orc Software w/CameronFIX 1 Aug 2008 10:32AM ET Re: Fast SCP David Rosenborg / Pantor Engineering AB 1 Aug 2008 10:58AM ET Re: Fast SCP Jean-Marie Sulmont / RTS 31 Jul 2008 10:19AM ET Re: Fast SCP Jean-Marie Sulmont / RTS 31 Jul 2008 10:41AM ET Re: Fast SCP David Rosenborg / Pantor Engineering AB 31 Jul 2008 11:10AM ET Re: Fast SCP Dimitry London / Morgan Stanley 7 Aug 2008 10:53PM ET
|
