|
FAST Protocol
< Previous Next >
Re: Calculated fields support
David Rosenborg / Pantor Engineering AB
25 Mar 2008 10:32AM ET No formal notation would be necessary to express that for example checksum and message length should be recalculated in a tunneling scenario. The FIX-over-FAST document should mention that such fields are not to be present in the FAST version of the message since they are artifacts of the tag=value encoding.
In earlier drafts of FAST there was the notion of a computed field, later renamed to implicit field, which was later droped alltogether since the construct was considered purely informational (and with very little practical value)
As discussed earlier, timestamps are best (most compact and efficiently) represented as a number of milli/nano/seconds since an EPOCH, together with the delta operator. What we need to discuss further is how to indicate the resolution and epoch used for a particular field.
Sending timestamps as strings should still be an option, but designing string de-/composition trickery seems suboptimal and defeats the purpose of FAST beeing efficient. If you want a simple solution in an otherwise string based context stick with full tsp strings and a suitable operator. If you want best overall performance, send integers with e.g. milliseconds since EPOCH.
For the timestamp handling I agree we'll need some formal notation. Ideally the next revision of FAST will include a special timestamp datatype for this purpose. In the meantime, some simple heuristcs and documentation in the FIX-over-FAST doucment would cover the most basic and immediate needs.
/David
> On the call the need to represent calculated fields in meta data was
> discussed by Hanno and Greg. The feeling was, in a tunneling scenario
> where a FIX tag=value message is being reconstructed, there should be a
> standard way of indicating fields, such as checksum, message length need
> to be recalculated.
>
> Hanno added that sometimes one FIX field might be segments, such as
> CFICode into constituent parts. Would it be useful to have meta data on
> how to reconstruct the data from its constituent FAST fields?
>
> Response from Hanno:
>
> Another example for the concatenation is again the UTCTimestamp
> datatype in FIX. If it can be split into date+time on the wire, then
> date can be coded very efficiently as a constant if it does not change
> during the session, requiring only time to be sent on the wire. The
> receiving end can put the two fields back together to create a valid
> FIX datatype again.
Re: Calculated fields support
David Rosenborg / Pantor Engineering AB 25 Mar 2008 10:32AM ET
|
@FIXProtocol
