[This message was posted by Jacob Northey of The LaSalle Technology Group
<[EMAIL PROTECTED]> to the "FAST Protocol" discussion forum at
http://fixprotocol.org/discuss/46. You can reply to it on-line at
http://fixprotocol.org/discuss/read/36c9f795 - PLEASE DO NOT REPLY BY MAIL.]
I wanted to comment on this extension proposal, but did not see a thread so I
will start one here by using the current Extension Proposals document as a
starting point.
Jake
EXTENSION PROPOSAL - MAP INLINE (table of {bit value, real value} pairs)
Background
In some cases, fields with a small number of values (such as Boolean or
‘OrdType’) could be represented with fewer than 7 bits, which is the minimum
wire size for a FAST field. The recent BITGROUP proposal is a mechanism to
combine several fields together so they can better use these 7 bits (or 14 or
21...). Greater efficiency could be realized by ‘inlining’ these few bits into
the pmap itself.
Introduction
An INLINE operator combined with a MAP will define a small number of bits to
represent the actvalues being expressed. Early on in FAST, we discussed using
another bit of pmap for a NULL flag, but chose to use NULL values instead for
consistency. The same argument was made for Boolean values represented in pmap
– consistency won out. This proposal argues that expanding pmap bit usage to
include inline field values gives sufficient compression to warrant the
complexity.
Examples
Assume we have the field MDUpdateAction which will use values 0, 1, and 2. This
could be expressed with a simple MAP INLINE:
{ 00, “0” }
{ 01, “1” } { 10, “2” } An extension of this technique could be used for
variable bit fields:
{ 0, “0” }
{ 10, “1” } { 11, “2” } Another example would by OrdType (optional in MDEntry).
To support NULL values, you could express the map like this:
{ 0, NULL }
{ 10, “0” } { 11, “1” } Thus, this field takes 1 or 2 bits instead of one byte.
Wire Representation
The wire format would necessarily change. When the next field in the template
uses MAP INLINE, there would be no field in the message body (after the pmap),
rather, that data would be in the pmap itself. So the next bits in the pmap
would be used to traverse the map.
[You can unsubscribe from this discussion group by sending a message to
mailto:[EMAIL PROTECTED]
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Financial Information eXchange" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/FIX-Protocol?hl=en
-~----------~----~----~----~------~----~------~--~---
