Imported from previous forum
I am analysing the choices : Upgrading to higher FIX version -vs- Custom message types -vs- User defined fields -vs- Multipe sessions ( one per FIX version ) between same parties -vs- Mixing different FIX versions in same session
- Upgrading to higher FIX version - is the best and cleanest, but costliest option.
http://www.fixprotocol.org/discuss/read/bdf97d6e
-
Custom message types - 2nd best approach, may require changes on FIX engine to handle custom messages.
-
User defined fields - 3nd best approach, may require changes on FIX engine to handle user defined fields.
http://www.fixprotocol.org/discuss/read/bca23e05
http://www.fixprotocol.org/discuss/read/1d3fcdea
- Multipe sessions ( one per FIX version ) between same parties - Good option, commonly used.
http://www.fixprotocol.org/discuss/read/3b2ba5aa
Advantage : each session can be different i.e. one can be FIXML and another can be Tag=Value^. But in some cases, this may not yeild the desirable benefits to both parties, especially if enterprise application integration between systems “on the other end” is not complete.
- Mixing different FIX versions in same session - good option but in some cases, this may not be a feasible option because of limitations of some existing software which does not permit mixing different FIX version messages in the same session.
In my fix engine whiched I developed in Java
http://www.fixprotocol.org/discuss/read/c8f36002
I could mix different versions of FIX messages in the same session ( but the different version messages had to be all Tag=Value^ - I have not yet extended this experiment to mixing different only FIXML versions in same session, but my guess is it should work fine. One more experiment to try is mixing FIXML and Tag=Value^ in same session ).
Does FIX protocol have any restriction in this regard ? Any pointers in this direction welcome.
Regards,
-Mahesh
Phone :-
Mobile : +1-203-252-4039
[ original email was from Jeremy Sutton - jezza.sutton@patsystems.com ]
Generally I find that using custom messages are not a best practise - sometimes requiring changes to FIX engines as you say. Likewise for custom tags - if they are to be used they should be registered with FPL and publicised.
The mixed approach which I think makes a great deal of sense and makes progress towards upgrading versions is to negotiate that the FIX.4.2 session will support an entire new message from a higher FIX version. For example, to support multi-leg orders in FIX.4.2 you could accept the AB message from FIX.4.3 in it’s fully 4.3+ compliant manner, keeping the remaining messages in their 4.2 compliant manner.
In this case for Tag 35 = AB would tag 8 = FIX.4.3 or FIX.4.2 ?
Regards,
-Mahesh
Phone :-
Mobile : +1-203-252-4039
[ original email was from Matt Simpson - msimpson@cme.com ]
Hi Mahesh -
This idea is being considered in the GTC and there should be an extension of the specification next year to allow message versions to be mixed within a given version of the FIX Session Layer. We refer to this as ‘transport independence’ since the application layer is specified independent of the session layer.
Initial thoughts around this are that the Logon would determine the FIX Session verion (eg 4.2) and BeginString on each application message would determine the FIX version to which that message belongs (eg 4.2, 4.3, etc). We’ll be sure to involve the FIX community as progress is made.
[quote] To support multi-leg orders in FIX.4.2 you could accept the AB
message from FIX.4.3 in it’s fully 4.3+ compliant manner, keeping the
remaining messages in their 4.2 compliant manner. [/quote]In this case for Tag 35 = AB would tag 8 = FIX.4.3 or FIX.4.2 ?
Regards, -Mahesh
Phone :-
Mobile : +1-203-252-4039
[ original email was from Ryan Pierce - rpierce@taltrade.com ]
> Initial thoughts around this are that the Logon would determine the
FIX Session verion (eg 4.2) and BeginString on each application
message would determine the FIX version to which that message belongs
(eg 4.2, 4.3, etc). We’ll be sure to involve the FIX community as
progress is made.
I’ve done the implementation that the client suggested (Multileg orders in FIX 4.2) and taken a different approach. The method I used was to send 8=FIX.4.2 35=AB
My reasoning is that many FIX engines validate tag 8, but not all engines validate the rest of the message outside of guaranteeing that it is well-formed (i.e. in Tag=Value[SOH] format, has a valid checksum and length, required header fields are present) and in sequence. Inserting 8=FIX.4.3 on an otherwise 4.2 session could cause problems with some engines.
Initial thoughts around this are that the Logon would determine the
FIX Session verion (eg 4.2) and BeginString on each application
message would determine the FIX version to which that message belongs
(eg 4.2, 4.3, etc). We’ll be sure to involve the FIX community as
progress is made.I’ve done the implementation that the client suggested (Multileg orders
in FIX 4.2) and taken a different approach. The method I used was to
send 8=FIX.4.2 35=ABMy reasoning is that many FIX engines validate tag 8, but not all
engines validate the rest of the message outside of guaranteeing that
it is well-formed (i.e. in Tag=Value[SOH] format, has a valid checksum
and length, required header fields are present) and in sequence.
Inserting 8=FIX.4.3 on an otherwise 4.2 session could cause problems
with some engines.
How come the FIX engine is able to accept a Tag35=AB as a Tag8=FIX.4.2 message ? Is there no validation to say that FIX.4.2 has no Tag35=AB message ?
Based on this, I do not see any use for Tag 8 / BeginString / FIX version. Even on a Logon message there may be no practical use for FIX version.
Is this tag 8 in place more to support backward compatibility / not break existing applications rather than add any value “it is present since the beginning so leave it untouched” thinking ?
Regards,
-Mahesh
Phone :-
Mobile : +1-203-252-4039
[ original email was from Ryan Pierce - rpierce@taltrade.com ]
How come the FIX engine is able to accept a Tag35=AB as a
Tag8=FIX.4.2 message ? Is there no validation to say that FIX.4.2 has
no Tag35=AB message ?
First, mixing versions isn’t technically FIX compliant. I don’t recall any official statement from FPL that it is allowed. As has been posted, FPL is beginning to look into this. But there has been an unofficial trend to pull new features into previous versions. For example, DiscretionInst and DiscretionOffset weren’t introduced until FIX 4.2. But my firm’s OMS will accept them in FIX 4.0 and 4.1 sessions as well. Still, all of this falls outside the realm of FIX compliance and into the realm of bilateral negotiations among counterparties.
Second, FPL defines the FIX Protocol, not any API between FIX engines and applications, or any list of validations that engines must perform. The spec certainly defines things that are illegal, but it doesn’t state whether the engine or the application has the responsibility to catch them.
The amount of validation built into the engine is going to vary based upon engine provider, and it might even be configurable. An engine that does minimal validation might not even check MsgType relative to the FIX spec version; it might assume that any message it doesn’t explicitly need to process (i.e. the session-level messages) should be handed off to the application for processing. So in this case, 35=AB in a FIX 4.2 message might get routed to the application… or it might not should the engine validate MsgType. Again, this falls under bilateral agreement between the parties.
Based on this, I do not see any use for Tag 8 / BeginString / FIX
version. Even on a Logon message there may be no practical use for
FIX version.
I don’t believe that is true, for several reasons:
While the FIX session has stayed fairly consistent across versions, there have been changes that engines must remain aware of. For example, in FIX 4.0 and 4.1, there was an effective limit of 999999 messages because that was used in Resend Requests. FIX 4.2 defined EndSeqNo=0 to represent infinity. So an engine must know what FIX version it is running. Placing it in the message allows an engine to auto-detect the FIX version of a counterparty, or in the case where FIX version is configured in advance, it allows the engine to verify that its counterparty is using the same FIX version.
The application generally needs to know what FIX version to use in formatting messages. There have been numerous changes in application messages, order state change matrices, etc. between FIX versions.
There needs to be a way to mark the beginning of a message. A parser can look for the string “8=FIX.” and it knows that a message is beginning. Then it can use the message length to see how much more data should be parsed. Then it can look again for “8=FIX.”
Hi Matt,
In a different discussion forum in this website, we are looking at the possibility of mixing different FIX versions of Session messages in same session.
http://fixprotocol.org/discuss/read/e772ea40
Would the proposed ‘transport independence’ be able to accomodate this ?
Regards,
K. Mahesh
Hi Mahesh -
This idea is being considered in the GTC and there should be an
extension of the specification next year to allow message versions to be
mixed within a given version of the FIX Session Layer. We refer to this
as ‘transport independence’ since the application layer is specified
independent of the session layer.Initial thoughts around this are that the Logon would determine the
FIX Session verion (eg 4.2) and BeginString on each application
message would determine the FIX version to which that message belongs
(eg 4.2, 4.3, etc). We’ll be sure to involve the FIX community as
progress is made.[quote] To support multi-leg orders in FIX.4.2 you could accept the AB
message from FIX.4.3 in it’s fully 4.3+ compliant manner, keeping the
remaining messages in their 4.2 compliant manner. [/quote]In this case for Tag 35 = AB would tag 8 = FIX.4.3 or FIX.4.2 ?
Regards, -Mahesh
Phone :-
Mobile : +1-203-252-4039
[ original email was from Matt Simpson - msimpson@cme.com ]
Hi Mahesh -
Sorry for the delayed response. No, we haven’t considered mixing session level messages. This seems like it could be problematic. At this point the proposal is to support a single version of FIX Session with multiple versions of the FIX application messages. Can you shoot me your ideas offline and we can discuss futher?
Hi Matt,
In a different discussion forum in this website, we are looking at the
possibility of mixing different FIX versions of Session messages in
same session.http://fixprotocol.org/discuss/read/e772ea40
Would the proposed ‘transport independence’ be able to accomodate this ?
Regards,
K. Mahesh