[This message was posted by heshan jayawardena of Millennium Information Technolog <[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/7b67efc0 - PLEASE DO NOT REPLY BY MAIL.]
it is totally understood that the session and the FAST protocol is independant. My main question was to figure whether its a violation of the FAST protocol to have no templates for some messages and send it without field encoding. > To have more examples to look at, it could make sense to look at the CME > feed. Specifically, there is a recovery channel that uses TCP with FIX > Classic for inbound messages and FIX over FAST for outbound messages. > Their mechanism minimizes the burden of session level handling and the > number of messages to support and is therefore not fully applicable to > your model. > > On the session layer side, a modern FIX engine separates the wire > representation layer (i.e. FIX Classic, FAST, ...) from the processing > of the session layer. The session layer should be ignorant of the wire > representation. The implementation effort in using a assymetric > transport would vary depending on what engines are involved I guess. > > Kind Regards, Anders Furuhed > > > that makes sense. if someone who doesn't use FIX will have to handle > > FAST to their format AND then in the requests they send they'd have to > > use Internal to FIX. Performance hit and complexity both i guess. > > > > But being a point to point implementation I'm quite unsure how i could > > have my session layer which is in FIX handle without the subscribers > > being able to handle FIX. I totally understand in multicast > > implementation such as ARCA or ISE heartbeats and gapfills aren't > > required at all but being a TCP recovery would be done by the FIX > > session. > > > > Correct me if i'm wrong. > > > > > > > Heshan, > > > > > > if a recipient decides to decode/encode the FAST encoded messages > > > to/from FIX then he obviously has to decode/encode the FIX encoded > > > messages to/from whatever internal format he'll use when processing > > > the received/sent messages but if he doesn't pass FIX on his way > > > from/to his internal format then he'll need both FAST<->internal and > > > FIX<->internal (ie. two codec impls). > > > > > > Anyone serious about performance will avoid the extra step of doing > > > FAST<->FIX<- > > > >internal. FAST<->FIX and FIX<->internal are both much more resource > > > consuming than FAST<->internal. > > > > > > You can do FAST in one direction and FIX in the other, but if you > > > want to be able to test your own stuff, then you have to implement > > > the other side and ... the other half of each codec. > > > > > > I would suggest that you spend time to do a proper impl so you don't > > > get hit resource-wise by the fact that you need a few more messages. > > > That will most definitely pay off in the longer term. > > > > > > /Rolf > > > > > > > hi Rolf, > > > > > > > > well the application messages are based on FIX.5.0.SP1. I'm not > > > > sure what you mean why two codecs. > > > > > > > > and answering your question YES more than one order books combined > > > > to create one large Consolidated order book for each instrument, > > > > but your 2nd question i cannot answer yet as it's a undisclosed > > > > client of ours. It's a Fixed-income venue. Probably not called an > > > > Exchange more like a Inter-dealer broker. > > > > > > > > > > > > > Hi Heshan, > > > > > > > > > > Mixing formats will force recipients to have support for two > > > > > codecs. > > > > > > > > > > What format do you consider using for the request messages? > > > > > > > > > > Out of curiosity: Consolidated means more than one source. Which > > > > > exchange are we talking about? > > > > > > > > > > /Rolf > > > > > [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 FIX-Protocol@googlegroups.com 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 -~----------~----~----~----~------~----~------~--~---
