[This message was posted by Marc Battyani of HPC Platform <[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/f87d4cc9 - PLEASE DO NOT REPLY BY MAIL.]
Hi, Here is our feedback on the fast 1.2 extension proposal. Our comments are obviously biased by our ns latency concern. New type definition syntax: OK Enumeration: OK Set: OK Bit Group: OK PMAP field placement: OK For the Bit group and the PMAP field placement, special care should be taken to properly define how they interact with the PMAP and the operators. Default and copy are probably the only safe operators usable with Bit groups, enum and set anyway. The PMAP fields should be restricted to a few bits only. For an uInt7 there is nothing to gain by putting it into the PMAP and for uInt6 you only gain 1 bit. This will be very good though for bits or very small enum/sets though. Timestamp: OK. Map is really not OK! 1- It breaks the FAST conceptual model where both the sender and receiver share a pre-defined set of templates. With this, you will also need a long term context and a large memory. There are already a context used for the operators like copy/inc/etc. but it's a short term one generally limited in scope to one multicast frame for instance and also its memory use is known and small. 2 - As it's a dynamic construct, it can't be optimized at compile time and so will be slow. 3- It will not work reliably. FAST is used a lot in multicast and unicast market data diffusion. So what do you do when you loose a packet? How do you know if you are in sync with the sender? When you start to process a feed, how do you get the current map? A giant snapshot? As consecutive IDs are not mandatory, you can't use an array and so you will need to use an hash table (or trees, skip-lists, whatever) and this will use a lot of memory and will be SLOW. So when I read "only a number of thousand values" I get really scared for the latency. ;-) So IMO this should not be added to FAST as it's really not fast at all. If really it is added to FAST, let's at least force it to use consecutive IDs. Note that a pre-shared map is just a big enum and that is OK of course. Best regards, Marc [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 -~----------~----~----~----~------~----~------~--~---
