RE: [Quickfix-developers] isCorrectCompID

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

Oren, Brian
I agree with your observations. Thank you very much for sharing it.

Prima facie, I have not much justification in thinking about any QuickFIX c=
hange on this, Oren's suggestion is reasonably trying to accommodate CME FI=
X violations, and at the same time letting users use QuickFIX for CME.

As for the pattern matching, I was thinking more in terms of virtualising t=
his validation interface to user - for those who need it (the default is fi=
ne) - rather than allowing skipping through configuration. However, it is t=
rue that, once we skip validation via configuration, we then have the oppor=
tunity to validate in toAdmin/fromAdmin.=20

Thanks.

Anil Jain

-----Original Message-----
From: Brian Erst [mailto:azz...@ya...]
Sent: Wednesday, May 10, 2006 1:56 PM
To: Oren Miller; Jain, Anil; rho;
qui...@li...
Subject: Re: [Quickfix-developers] isCorrectCompID

Oren -

Just to make you aware, CME really does violence to the whole SenderCompID =
tag. When they created their new FIX gateway a few years back, they removed=
 just about all the routing intelligence that had been built into the old o=
ne. Due to this fact, they ended up needing a field that would allow both t=
he failover routing (that whole "U" versus "P" thing) as well as multi-clea=
ring firm support (for instance, one of my clients clears under 5-6 differe=
nt clearing firm numbers due to a number of acquisitions over the years).=20

Rather than putting that into a user defined field as they should have done=
 (or better still, Sender/TargetSubID), they used SenderCompID to handle it=
. You have a "master" session that you login with, but after that, the Send=
erCompID is split into three parts: a session identifier (3 chars), a clear=
ing firm number (3 numbers) and a failover indicator ("U", "P" or "N"). As =
long as your session id (first 3 chars) doesn't change and your firm number=
 (second 3 chars) is registered, you can modify things to your hearts conte=
nt.=20

It's the only way for big firms to enter orders using a single login. While=
 it ridiculously breaks FIX semantics for no good reason, it's far preferab=
le to other exchanges (Liffe/CBOT, I'm looking at you) that require separat=
e logins for each clearing firm number.

We run our own custom-developed FIX engine just for CME because it's such a=
n odd duck, FIX-wise. I like to think of it as "FIX inspired", rather than =
true FIX.

- Brian Erst
Thynk Software, Inc.

----- Original Message ----
From: Oren Miller <or...@qu...>
To: "Jain, Anil" <Ani...@rb...>; rho <tia...@ya...>; quick=
fix...@li...
Sent: Wednesday, May 10, 2006 12:32:58 PM
Subject: Re: [Quickfix-developers] isCorrectCompID

QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/html/ind=
ex.html
QuickFIX Support: http://www.quickfixengine.org/services.html

Well, the CME made the choice to break FIX compatibility by sending multipl=
e=20
comp ids on a single session.  Adding pattern matching or regex comparisons=20
to compids adds a lot of complexity with no real tangible benefit.  The sam=
e=20
goes for systems that choose to send some fields with no data.  Our solutio=
n=20
is going to be to turn turn off that validation for all fields in those=20
cases.  We don't intend on writing a validation system that will do that=20
validation for some fields and not for others.  The added effort and=20
complexity is just not worth it.

These are basic rules of the fix protocol.  By breaking this rule, the CME=20
is essentially saying that this rule does not apply.  Turning off the=20
validation is the simplest and most universal solution to the problem.  If=20
the CME has a habit of sending you messages from other sessions, then there=20
is a bigger problem they need to address.

--oren

----- Original Message -----=20
From: "Jain, Anil" <Ani...@rb...>
To: "Oren Miller" <or...@qu...>; "rho" <tia...@ya...>=
;=20
<qui...@li...>
Sent: Wednesday, May 10, 2006 12:18 PM
Subject: RE: [Quickfix-developers] isCorrectCompID

I do not understand your suggestion to make it configurable.
The validation, if it is needed, must be there, now that a pattern needs to=20
be validated, rather than a static data.
But, then neither have I used CME fault tolerance, nor I have sufficient QF=20
experience to encounter a failed validation in general.

Anil Jain

-----Original Message-----
From: qui...@li...
[mailto:qui...@li...]On Behalf Of
Oren Miller
Sent: Wednesday, May 10, 2006 1:02 PM
To: rho; qui...@li...
Subject: Re: [Quickfix-developers] isCorrectCompID

QuickFIX Documentation:=20
http://www.quickfixengine.org/quickfix/doc/html/index.html
QuickFIX Support: http://www.quickfixengine.org/services.html

Yeah, this is just a quick workaround.  In the end we will probably need to
add another validation config setting such as ValidateSenderCompID.

--oren

----- Original Message -----=20
From: "rho" <tia...@ya...>
To: <qui...@li...>
Sent: Wednesday, May 10, 2006 11:53 AM
Subject: Re: [Quickfix-developers] isCorrectCompID

> QuickFIX Documentation:
> http://www.quickfixengine.org/quickfix/doc/html/index.html
> QuickFIX Support: http://www.quickfixengine.org/services.html
>
>
> The easy way to fix it is to modify the function one way or another. But
> that
> would mean a change of the quickfix library. I tried not to change the
> quickfix library.
>
> --
_______________________________________________________________________

This E-Mail (including any attachments) may contain privileged or confident=
ial information.  It is intended only for the addressee(s) indicated above.
The sender does not waive any of its rights, privileges or other protection=
s respecting this information. =20
Any distribution, copying or other use of this E-Mail or the information it=
 contains, by other than an intended recipient, is not sanctioned and is pr=
ohibited.
If you received this E-Mail in error, please delete it and advise the sende=
r (by return E-Mail or otherwise) immediately.

This E-Mail (including any attachments) has been scanned for viruses.=20
It is believed to be free of any virus or other defect that might affect an=
y computer system into which it is received and opened.=20
However, it is the responsibility of the recipient to ensure that it is vir=
us free.=20
The sender accepts no responsibility for any loss or damage arising in any =
way from its use.

E-Mail received by or sent from RBC Capital Markets is subject to review by=
 Supervisory personnel.=20
Such communications are retained and may be produced to regulatory authorit=
ies or others with legal rights to the information.