[This message was posted by Brandon Yuille of BWY Systems <[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/d374abfc - PLEASE DO NOT REPLY BY MAIL.]
Thanks Rolf, I thought I was going crazy there for a second. Your post has thoroughly answered my question. As for causing offense, I think I was confusing replies directed towards another poster on this thread. What I meant in my earlier post about just set the tid to NULL, is that the NULL value of the tid (if it were to precede the pmap) could imply it is to be copied (so worst case it would take 1 byte). The reason this could work is because the tid would no longer be a normal field as it does not follow the pmap and to answer Dale's response what would the sense of NULL for the tid meaning "not present" be when every FAST message must have a template associated with it to be decoded? Anyway, I was unaware that you guys had thought about this, so if it wasn't found beneficial in 2005 then it probably won't in the future. Thanks for listening Rolf, Brandon > Brandon, > > your point is valid and I don't think your comments have offended > anyone. We actually had the tid before the pmap in one of our test > versions of the protocol during development back in 2005. Then we found > that on some actual live data (ARCA if I recall correctly), we could > save 5-10% of the transfer size. So we decided to put the tid after the > pmap, thus being able to use copy coding. This decision was based on our > empirical tests, and I believe that we were able to show that this > arrangement had a marginal impact on performance. > > Best, Rolf > > > > I'm resigning trying to explain my point. It doesn't seem like anyone > > wants to actually read what I'm saying. I was honestly trying to help > > the protocol be more efficient so for anyone taking offense to my > > comments please don't. > > > > Oh and for the record I have not a clue what Majkara is talking about. > > > > Brandon > > > > > > That's why I was suggesting that if there is to be another FAST > > > > version, it might be a good update to move the template id to the > > > > beginning of the message and you can even set it to NULL if it is > > > > to be copied from a previous message. > > > > > > That doesn't make sense. A NULL value means the field is not present > > > in this record. The TID must be present. > > > > > > A zero PMAP bit for a field means the field is not present _on the > > > wire_. To answer your earlier question, "Yes there are FAST data > > > sources that omit the TID on the wire, relying on the implicit copy > > > operator for the template ID. For this to work, the PMAP must come > > > first. > > > > > > If this is a problem for your implementation, I might respectfully > > > suggest you change your implementation rather than trying to change > > > the protocol. > > > > > > Dale [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.
