Re: [Quickfix-developers] FAST FIX

[Oren M. <or...@qu...>]

Supporting CME has been an important goal for QuickFIX, and will  
continue to be with our FAST implementation.  Much of the work we  
have done for compatibility has been from feedback by users who are  
connected to the CME.  I know there are many firms that currently use  
QuickFIX with the CME.  We know they have a funny implementation and  
have worked to support it.

I know we did work to support their funny usage of compids, though  
from your description I'm not sure if it is exactly what we worked on  
or not.  Anybody who is connected that can comment on it?

Required fields aren't such a big deal because you can change how  
messages are validated.  So QuickFIX doesn't have to care so much  
about required fields.

--oren

On Jul 23, 2007, at 3:42 PM, Brian Erst wrote:

> Oren -
>
> Are you planning to support the CME's networking layer (dual UDP  
> streams) in your new FAST engine? I ask because CME has been the  
> primary driver for FAST, and that implementation (a SIAC-like UDP  
> networking layer coupled with FAST messaging) is probably going to  
> be the first version that hits production.
>
> Second question - which may already have been asked and answered  
> somewhere - can QuickFIX handle the CME's broken FIX  
> implementation? They really borked up two aspects:
>
> 1. They overload the meaning of the SenderCompID. They use it for  
> primary/backup/failover purposes and to allow multi-firm routing.  
> It's bizarre - the first three characters of the SenderCompID  
> identify the API "user", the next three identify the firm  
> submitting the current order, and the last character indicates  
> which server you think you're connecting to - primary or backup (or  
> "N" if you don't care/can't handle failover). The "session" is  
> defined purely in terms of the first three characters - I can send  
> "ABC123P" and "ABC987B" on the same "session". In practice (as we  
> don't use failover), we end up just modifying the "middle" three  
> characters to handle multi-membership routing.
>
> 2. They don't send all the required fields on fills of spread  
> orders on their "Eagle" markets. Instead of sending a  
> "differential" fill or leg fills, they send a weird combination of  
> a differential fill, followed by two "leg" fills that are missing a  
> lot of required FIX fields for execution reports. You're supposed  
> to fill in the missing fields on the legs with data from the  
> differential.
>
> Because of the above, we run a custom "FIX-like" engine that I  
> wrote to handle their mess. Anyone dealing with CME that has  
> managed to get QuickFIX to work with it? I'd imagine unmodified QF  
> would run screaming from their message flow...
>
> - Brian Erst
>
> ----- Original Message ----
> From: Oren Miller <or...@qu...>
> To: Caleb Epstein <cal...@gm...>
> Cc: qui...@li...
> Sent: Monday, July 23, 2007 3:05:39 PM
> Subject: Re: [Quickfix-developers] FAST FIX
>
> QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/ 
> html/index.html
> QuickFIX Support: http://www.quickfixengine.org/services.html
>
> We are doing work on FAST, though it will not be using the QuickFIX
> API for the reasons you noted.  It will have a new API that is better
> suited to the task.
>
> --oren
>
> On Jul 23, 2007, at 3:02 PM, Caleb Epstein wrote:
>
> > QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/
> > html/index.html
> > QuickFIX Support: http://www.quickfixengine.org/services.html
> >
> > On 7/23/07, Shawn Yarbrough <sya...@ge...> wrote:
> >
> >> I'm searching for information about QuickFIX and the new FAST/FIX
> >> protocol,
> >> but I wasn't able to find anything on the quickfixengine.org
> >> website.  Can
> >> you tell me anything about this?
> >
> > I don't think any work has been done to add FAST encoding into
> > QuickFIX.
> >
> > I believe FAST is still a 'proof of concept' and is generally being
> > used for very high volume, session-less traffic like market data
> > feeds.  Are any ECNs using it for order entry?  Has anyone gone
> > through the exercise of mapping (say) the FIX4.4 message
> > specifications to FAST message templates?
> >
> > Frankly, if there is no real "session" involved and you're just
> > consuming market data, I don't know that QuickFIX would be a
> > particularly good choice of APIs even if it did have FAST support.
> > You're probably better off with (say) the proof-of-concept FAST C
> > library  available from fixprotocol.org/fast.
> >
> > --
> > Caleb Epstein
> >
> >  
> ----------------------------------------------------------------------
> > ---
> > This SF.net email is sponsored by: Splunk Inc.
> > Still grepping through log files to find problems?  Stop.
> > Now Search log events and configuration files using AJAX and a
> > browser.
> > Download your FREE copy of Splunk now >>  http://get.splunk.com/
> > _______________________________________________
> > Quickfix-developers mailing list
> > Qui...@li...
> > https://lists.sourceforge.net/lists/listinfo/quickfix-developers
> >
>
>
> ---------------------------------------------------------------------- 
> ---
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a  
> browser.
> Download your FREE copy of Splunk now >>  http://get.splunk.com/
> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>
>