Imported from previous forum
My friends Russ and Clive have convinced me that we should errata FIXT.1.1 to require ApplVerID on all FIXT messages. The original vision was to be able to set the DefaultApplVerID in the logon and then have the application level messages independent of version, using ApplVerID only when you were overriding the default version.
So here is why I think they are correct.
-
Having to specify ApplVerID on every message costs at most 7 bytes.
-
Having ApplVerID required on every message does not impact mixing application versions over an existing session.
-
Eliminates having to maintain the state of the Application Version.
The last point is important - because many times you may not have the benefit of having a full session available say in monitoring and logging tools.
Long term we should be moving to make FIX messages so they can be initially parsed without a dictionary so FIX can be embedded in network infrastructure. Having to maintain a session level version state actually moves us away from that direction.
So I really think we should require ApplVerID on every message going forward. Thoughts?
[ original email was from Clive Browning - clive.browning@rapidaddition.co.uk ]
I agree… additionally note that if you are using a custom version or an EP this does also mean those 2 other fields also need to be present int all app messages.
Clive
My friends Russ and Clive have convinced me that we should errata
FIXT.1.1 to require ApplVerID on all FIXT messages. The original vision
was to be able to set the DefaultApplVerID in the logon and then have
the application level messages independent of version, using ApplVerID
only when you were overriding the default version.So here is why I think they are correct.
Having to specify ApplVerID on every message costs at most 7 bytes.
Having ApplVerID required on every message does not impact mixing
application versions over an existing session.Eliminates having to maintain the state of the Application Version.
The last point is important - because many times you may not have the
benefit of having a full session available say in monitoring and
logging tools.Long term we should be moving to make FIX messages so they can be
initially parsed without a dictionary so FIX can be embedded in network
infrastructure. Having to maintain a session level version state
actually moves us away from that direction.So I really think we should require ApplVerID on every message going
forward. Thoughts?
[ original email was from Clive Browning - clive.browning@rapidaddition.co.uk ]
To make it clearer… those additional fields are (assuming i get them correct):
ApplExtID: 1156
CstmApplVerID: 1129
Clive
I agree… additionally note that if you are using a custom version or
an EP this does also mean those 2 other fields also need to be present
int all app messages.Clive
My friends Russ and Clive have convinced me that we should errata
FIXT.1.1 to require ApplVerID on all FIXT messages. The original
vision was to be able to set the DefaultApplVerID in the logon and
then have the application level messages independent of version, using
ApplVerID only when you were overriding the default version.So here is why I think they are correct.
Having to specify ApplVerID on every message costs at most 7 bytes.
Having ApplVerID required on every message does not impact mixing
application versions over an existing session.Eliminates having to maintain the state of the Application Version.
The last point is important - because many times you may not have the
benefit of having a full session available say in monitoring and
logging tools.Long term we should be moving to make FIX messages so they can be
initially parsed without a dictionary so FIX can be embedded in
network infrastructure. Having to maintain a session level version
state actually moves us away from that direction.So I really think we should require ApplVerID on every message going
forward. Thoughts?
Jim,
Its is a good idea to reduce session state information.
So would DefaultApplVerID (1137) would be deprecated ? If every message would have ApplVerID (1128) then there is no meaning in a DefaultApplVerID in Logon message.
Regards,
Mahesh
My friends Russ and Clive have convinced me that we should errata
FIXT.1.1 to require ApplVerID on all FIXT messages. The original vision
was to be able to set the DefaultApplVerID in the logon and then have
the application level messages independent of version, using ApplVerID
only when you were overriding the default version.So here is why I think they are correct.
Having to specify ApplVerID on every message costs at most 7 bytes.
Having ApplVerID required on every message does not impact mixing
application versions over an existing session.Eliminates having to maintain the state of the Application Version.
The last point is important - because many times you may not have the
benefit of having a full session available say in monitoring and
logging tools.Long term we should be moving to make FIX messages so they can be
initially parsed without a dictionary so FIX can be embedded in network
infrastructure. Having to maintain a session level version state
actually moves us away from that direction.So I really think we should require ApplVerID on every message going
forward. Thoughts?
Mahesh,
I am certainly not opposed to the deprecation of DefaultApplVerID and would not oppose someone submitting such a proposal for the GTC to decide upon.
As you say with a required ApplVerID on each message - the use of DefaultApplVerID is greatly marginalized.
Jim,
Its is a good idea to reduce session state information.
So would DefaultApplVerID (1137) would be deprecated ? If every message
would have ApplVerID (1128) then there is no meaning in a
DefaultApplVerID in Logon message.Regards, Mahesh
My friends Russ and Clive have convinced me that we should errata
FIXT.1.1 to require ApplVerID on all FIXT messages. The original
vision was to be able to set the DefaultApplVerID in the logon and
then have the application level messages independent of version, using
ApplVerID only when you were overriding the default version.So here is why I think they are correct.
Having to specify ApplVerID on every message costs at most 7 bytes.
Having ApplVerID required on every message does not impact mixing
application versions over an existing session.Eliminates having to maintain the state of the Application Version.
The last point is important - because many times you may not have the
benefit of having a full session available say in monitoring and
logging tools.Long term we should be moving to make FIX messages so they can be
initially parsed without a dictionary so FIX can be embedded in
network infrastructure. Having to maintain a session level version
state actually moves us away from that direction.So I really think we should require ApplVerID on every message going
forward. Thoughts?
[ original email was from Clive Browning - clive.browning@rapidaddition.co.uk ]
I think this also applies to:
DefaultApplExtID (1407)
DefaultCstmApplID (1408)
Clive
Mahesh,
I am certainly not opposed to the deprecation of DefaultApplVerID and
would not oppose someone submitting such a proposal for the GTC to
decide upon.As you say with a required ApplVerID on each message - the use of
DefaultApplVerID is greatly marginalized.Jim,
Its is a good idea to reduce session state information.
So would DefaultApplVerID (1137) would be deprecated ? If every
message would have ApplVerID (1128) then there is no meaning in a
DefaultApplVerID in Logon message.Regards, Mahesh
My friends Russ and Clive have convinced me that we should errata
FIXT.1.1 to require ApplVerID on all FIXT messages. The original
vision was to be able to set the DefaultApplVerID in the logon and
then have the application level messages independent of version,
using ApplVerID only when you were overriding the default version.So here is why I think they are correct.
Having to specify ApplVerID on every message costs at most 7
bytes.Having ApplVerID required on every message does not impact mixing
application versions over an existing session.Eliminates having to maintain the state of the Application
Version.The last point is important - because many times you may not have
the benefit of having a full session available say in monitoring and
logging tools.Long term we should be moving to make FIX messages so they can be
initially parsed without a dictionary so FIX can be embedded in
network infrastructure. Having to maintain a session level version
state actually moves us away from that direction.So I really think we should require ApplVerID on every message going
forward. Thoughts?
My friends Russ and Clive have convinced me that we should errata
FIXT.1.1 to require ApplVerID on all FIXT messages. The original vision
was to be able to set the DefaultApplVerID in the logon and then have
the application level messages independent of version, using ApplVerID
only when you were overriding the default version.So here is why I think they are correct.
Having to specify ApplVerID on every message costs at most 7 bytes.
Having ApplVerID required on every message does not impact mixing
application versions over an existing session.Eliminates having to maintain the state of the Application Version.
The last point is important - because many times you may not have the
benefit of having a full session available say in monitoring and
logging tools.
Hi Jim, All:
I don’t know how the default application version identifier impacts the engine technology being produced by other firms, but I can provide an example of how this complicates things from our own experience with it:
If you’re building a FIX engine, using versions 4.0-4.4, it’s very easy to put together really clean software architectures for parsing messages and managing session state. Since you can parse any message in isolation, without having to know the details of the session that is currently in progress, you can have one single instance of a parser in your system, which then routes fully-parsed FIX messages to individual session state handlers (state machines) for each active session.
For instance, our FIX state machine interface, under FIX 4.0-4.4 looks a little like this:
class FixSession
{
…
// State machine reacts to an incoming message.
public void HandleRecvMsg(FixMessage m);
// State machine reacts to user sending a message.
public void HandleSendMsg(FixMessage m);
…
}
The introduction of the DefaultApplVerID required us to do something like this:
class FixSession
{
…
// State machine receives raw data from peer system
// and uses internal parser to figure it out…
public void HandleRecvMsg(RAW_DATA_FROM_PEER m);
// State machine reacts to user sending a message.
public void HandleSendMsg(FixMessage m);
...
}
Obviously, there are other ways to skin the cat, but the biggest issue with DefaultApplVerID (at least from my perspective) is that it forces you to incorporate knowledge about parsing into your session, or knowledge about your session into your parser. You go from a really clean model of having a single parser and multiple sessions, to a model where you are forced to mix the concepts of parsing and session state at some point in your architecture.
Also, the point that Jim raises about having to know the LOGON message in order to decipher other messages is a big one. Not being able to validate a message in isolation seems to raise some real issues for people who are developing monitoring/management tools for FIX-based systems.
Especially having to find the logon message in a session to establish the Application Version is particularly onerous during operations - because often there is something broken and an orderly session may not be available.
[ original email was from Ryan Pierce (FPL Technical Director) - ryan.pierce@fixprotocol.org ]
> My friends Russ and Clive have convinced me that we should errata
FIXT.1.1 to require ApplVerID on all FIXT messages.
[snip]
So I really think we should require ApplVerID on every message going
forward. Thoughts?
My thoughts on this:
-
These are excellent, compelling arguments. I agree that the complications of imposing state on parsing far outweigh the (very small) bandwidth expended to indicate application version on every application message.
-
This will just be required on application messages only, correct? Changing this in the StandardHeader to Required would have the effect of requiring it on session messages, which wouldn’t make sense. Would this be expressed as a conditional requirement?
-
While I believe requiring version on application messages is a good thing and should be done in the next FIXT version, I question if we should errata FIXT.1.1 to require it at this point. Doing so could conceivably break compatibility between pre-errata and post-errata FIXT.1.1 engines.
-
Mahesh points out that required DefaultApplVerID on the Logon (and the other 2 tags) would no longer be used to set a default state used by the parser. However, they do serve another important operational purpose, and I question if we should deprecate them.
Most exchanges support only one FIX version, or a limited subset of versions. Prior to FIX 5.0/FIXT, BeginString could be used to check that the client was speaking a version of FIX that the exchange supported, terminating the session if this was not the case. With FIXT, it is possible to surprise an exchange with an unexpected application message version. But the exchange can validate the default application version sent in the Logon. So as long as the member doesn’t deviate from the default version, there won’t be any surprises.
If DefaultApplVerID isn’t required on the Logon, an unsupported version likely won’t be detected until the first order is sent. From an operational standpoint, I’d rather have an indication that something is wrong immediately when I bring up my session, rather than at the open when all my orders are rejected.
I agree with Ryan its better to make these changes in the next FIXT version.
When a single FIX version is being supported, would they be using FIXT.1.1 or higher or would they just use FIX.m.n session?
Assuming they use FIXT session to support a single FIX version, the default application version sent in Logon would help the Logon receipent to validate the FIX version of subsequent messages.
If FIXT session is being used to support more than one FIX application version which is what FIXT sessions are expected to be used for, I do not see what use default application version fields would serve because as per FIXT.1.1 these fields are not a repeating group, so only one value can be specified. In this case, I would say we would need a new component / new fields which would be part of a repeating group in Logon message which would be as follows :-
Start Component = PermittedApplVersions
Start Repeating Group = NoPermittedApplVersions
First Reqd field = PermittedApplVersion
Next Opt field = PermittedApplExtID
Next Opt field = PermittedCstmApplID
End Repeating Group
End Component
This would replace DefaultApplVerID (1137), DefaultApplExtID (1407) and DefaultCstmApplID (1408) fields in Logon message.
This would permit establishing at the time of Logon what verions of messages are permitted to be exchanged and if the receipent of Logon message finds values in the above new block which it will not support, then the session can be terminated with a Logout with text “Unsupported …”. If Logon is successful it would mean that both parties have agreed upon what versions are permitted and if later a message is received which has version / extid / customid which is not supported by receipent, then that one message can be rejected.