Version Handling with Transport Independence

, ,
1

Imported from previous forum

2

Hi,

I have a scenario involving 2 firms on different versions of FIX and wanting to communicate with each other via FIX. Hoping someone can help clarify:

Firm A: using 5.0
Firm B: using 4.2

  1. What’s the benefit of using the transport independence framework in this case? How does it help facilitate communication?

  2. I’m assuming in order to communicate to a different version, usage of tags and internal systems handling would still be needed?

Thank you.
Rich

3

Transport Independence is the de-coupling of the FIX session and application layer. It allows systems to send FIX messages over a non-FIX transport, like Tibco, MQSeries, Web Services, etc.

whereas

Application Version Independence is the ability of a single FIX session to support multiple FIX application versions.

Before FIXT.1.1 (upto FIX.4.4), FIX session version and the FIX application version had to be the same. The scenario you are describing below is Application version independence which often gets bundled under Transport Independence and it is helpful to consider them separately.

Firm A is using FIX application version 5.0
Firm B is using FIX application version 4.2

What versions of FIX sessions are they using? My guess is that Firm A’s session is FIXT.1.1 and Firm B’s session is FIX.4.2

For any two FIX engines to communicate with each other, the first requirement is that both of them should use the same FIX session version for that session. So in your case Firm B would have to upgrade their FIX engine to support FIXT.1.1 session.

HTH

Hi,

I have a scenario involving 2 firms on different versions of FIX and wanting to communicate with each other via FIX. Hoping someone can help clarify:

Firm A: using 5.0
Firm B: using 4.2

  1. What’s the benefit of using the transport independence framework in this case? How does it help facilitate communication?

  2. I’m assuming in order to communicate to a different version, usage of tags and internal systems handling would still be needed?

Thank you.
Rich

4

Thank you for your response.

I’ve heard there was some level of “backwards compatability” offered by version 5.0. I wasn’t sure what that meant? Any thoughts?

As you stated below, my understanding was that both Firms A and B needed to
a. speak the same language at the session level in order to connect
b. speak the same language or have some tags/handling in place to translate the differences in the two languages.

Thanks.
Rich

Transport Independence is the de-coupling of the FIX session and application layer. It allows systems to send FIX messages over a non-FIX transport, like Tibco, MQSeries, Web Services, etc.

whereas

Application Version Independence is the ability of a single FIX session to support multiple FIX application versions.

Before FIXT.1.1 (upto FIX.4.4), FIX session version and the FIX application version had to be the same. The scenario you are describing below is Application version independence which often gets bundled under Transport Independence and it is helpful to consider them separately.

Firm A is using FIX application version 5.0
Firm B is using FIX application version 4.2

What versions of FIX sessions are they using? My guess is that Firm A’s session is FIXT.1.1 and Firm B’s session is FIX.4.2

For any two FIX engines to communicate with each other, the first requirement is that both of them should use the same FIX session version for that session. So in your case Firm B would have to upgrade their FIX engine to support FIXT.1.1 session.

HTH

Hi,

I have a scenario involving 2 firms on different versions of FIX and wanting to communicate with each other via FIX. Hoping someone can help clarify:

Firm A: using 5.0
Firm B: using 4.2

  1. What’s the benefit of using the transport independence framework in this case? How does it help facilitate communication?

  2. I’m assuming in order to communicate to a different version, usage of tags and internal systems handling would still be needed?

Thank you.
Rich

5

If by “Backward compability” you mean a FIX Application being able to handle “lower version” messages from the other side, then yes, FIXT.1.1 + FIX.5.0++ shall permit you backward compatibility by permitting application versioning using the following fields

DefaultApplVerID(1137)

RefMsgType(372), RefApplVerID(1130) & DefaultVerIndicator(1410)

ApplVerID(1128)

DefaultApplExtID(1407)

RefApplExtID(1406)

ApplExtID(1156)

DefaultCstmApplVerID(1408)

RefCstmApplVerID(1131)

CstmApplVerID(1129)

Refer FIX_Transport_1.1.pdf Pages 8/66 to 10/66 for details of usage and precedence rules of the above fields.

This backward compatibility is not applicable at session level, the FIX engines of both firms A and B need to use the same BeginString Tag 8 value which has to be FIXT.1.1 or higher, the above fields are for application messages versioning only.

The “have some tags/handling in place to translate the differences in the two versions” (c/s/w)ould be covered by rules of engagement because I do not see that aspect of Application version independence covered anywhere in the spec. My understanding is that interpretations from higher versions are used wherever applicable in terms of State change matrices etc. because later FIX versions have fixed ambiguties of earlier version’s interpretations.

Regards,
K. Mahesh

Thank you for your response.

I’ve heard there was some level of “backwards compatability” offered by version 5.0. I wasn’t sure what that meant? Any thoughts?

As you stated below, my understanding was that both Firms A and B needed to
a. speak the same language at the session level in order to connect
b. speak the same language or have some tags/handling in place to translate the differences in the two languages.

Thanks.
Rich

Transport Independence is the de-coupling of the FIX session and application layer. It allows systems to send FIX messages over a non-FIX transport, like Tibco, MQSeries, Web Services, etc.

whereas

Application Version Independence is the ability of a single FIX session to support multiple FIX application versions.

Before FIXT.1.1 (upto FIX.4.4), FIX session version and the FIX application version had to be the same. The scenario you are describing below is Application version independence which often gets bundled under Transport Independence and it is helpful to consider them separately.

Firm A is using FIX application version 5.0
Firm B is using FIX application version 4.2

What versions of FIX sessions are they using? My guess is that Firm A’s session is FIXT.1.1 and Firm B’s session is FIX.4.2

For any two FIX engines to communicate with each other, the first requirement is that both of them should use the same FIX session version for that session. So in your case Firm B would have to upgrade their FIX engine to support FIXT.1.1 session.

HTH

Hi,

I have a scenario involving 2 firms on different versions of FIX and wanting to communicate with each other via FIX. Hoping someone can help clarify:

Firm A: using 5.0
Firm B: using 4.2

  1. What’s the benefit of using the transport independence framework in this case? How does it help facilitate communication?

  2. I’m assuming in order to communicate to a different version, usage of tags and internal systems handling would still be needed?

Thank you.
Rich