[This message was posted by Anders Furuhed of Pantor Engineering <[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/f919286c - PLEASE DO NOT REPLY BY MAIL.]
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 -~----------~----~----~----~------~----~------~--~---
