Imported from previous forum
[ original email was from Jason Vinton - jvinton@neonsoft.com ]
I have a few concerns with the usage of the repeating group beginning with field 384, NoMsgTypes, in the logon message.
- The meaning of field 385, MsgDirection, is ambiguous. Field 385 has valid values of “S” or “R” for send and receive respectively. However, the FIX.4.2 specification does not define send and receive with respect to a particular party. For example, if party A receives a logon with New Order marked as send, it is unclear whether A’s counter party intends to send or receive New Orders.
I would define the basic functionality as follows:
“The Logon can be used to specify the message types supported during on a sending and receiving basis. In the logon message, the user may provide a list of valid supported application message types and the associated supported direction. The value of the send/receive flag in field 385, MsgDirection, is to be interpreted from the logon receiver’s point of view. (e.g. an incoming logon with a New Order indicated as receive denotes that the counterparty intends to send New Orders.) If this repeating group does not exist, then all messages are assumed to be valid per bilateral agreement.”
Unfortunately the 4.2 spec does not address how the acceptor should respond to the initiator’s list of allowed message types. Should the acceptor echo back the list to the initiator? With this approach, the acceptor is bound by the initiator’s wishes. Is the acceptor allowed to respond with a different list of allowed message types? If the acceptor responds with a different list of allowed messages, how are conflicts resolved? Is the list of allowed messages for the session defined as the set of messages in the union of the acceptor’s and the initiator’s allowed lists or in the intersection? In some cases, the initiator may not provide a list of valid messages at all, but the acceptor may respond with one. In this case, the union approach appears to make sense. If the initiator provides a list of supported messages, then one might assume that the initiator has provided a complete list. Therefore there is no need for the acceptor to echo back the list of valid messages, unless the acceptor wished to provide a shortened list. In this case, the intersection approach appears to make sense. The NEON solution attempts to be as flexible as possible. When running as the initiator, we use the intersection. When running as the acceptor, we respond by echoing back the initiator’s list of valid message types. I would be very interested in hearing from other venders concerning how they have approached this problem.
- The use of field 35, MsgType, in the logon message is problematic. In the “Field Definitions” section of the FIX.4.2 specification, field 35 is clearly defined. It can take on the value of ANY FIX message type, including administrative message types. Is it legal to include a heartbeat message in the list of legal messages? Is required include to heartbeat message in the list of legal messages? The intended use of field 35 is clear, it applies to application messages. However, from my point of view, it is only a matter of time before a client will encounter another’s vendor’s engine that implements a literal interpretation of the spec.
Proposed solution:
Define a new field, AppMsgType.
AppMsgType = {the set of all message types} - {the set of all administrative message types}
Use AppMsgType in place of MsgType.
This solution removes all possibility of interpretation problems.
I have one additional comment related to the use of field 35 in the logon message. The introduction of a field that is used in two distinctly different contexts can negatively effect the existing data structures used to hold the data from a FIX message. Till now, FIX message definitions have not had a single field used multiple times. Please note that fields in repeating structures appear multiple times, but within a single context. If a single field can be used in the message in multiple contexts, then data structures have to be rewritten to retrieved data based not only on repeat count and field Id, but also on context. I imagine many engines have been heavily optimized to retrieve field data only on field Id and, optionally, repeat count.
Thanks,
[ original email was from John Hardman - yiq12@dial.pipex.com ]
Regarding the last point raised - that of having the same field used in multiple contexts within a single message …
Some messages include pairings such as Symbol and Underlying Symbol to avoid conflicts. It would make sense for the Logon message to use a similar pairing (e.g. MsgType and SupportedMsgType, or similar) instead of repeating the same field in different contexts.
When writing a FIX engine to support only the pre-defined FIX 4.2 messages this is not a major issue. However, when writing a truly generic FIX engine that will support any message that meets the protocol specification (including user-defined messages containing both pre-defined and user-defined fields) having the same field in multiple contexts is a major headache. The algorithm needed in the FIX engine’s parser suddenly becomes a lot more complicated.
I would strongly support modifying the Logon message and adding a general rule that says that fields may not appear in multiple contexts within the same message.
Regards,
John Hardman.
> I have a few concerns with the usage of the repeating group beginning with field 384, NoMsgTypes, in the logon message.
>
> 1. The meaning of field 385, MsgDirection, is ambiguous. Field 385 has valid values of “S” or “R” for send and receive respectively. However, the FIX.4.2 specification does not define send and receive with respect to a particular party. For example, if party A receives a logon with New Order marked as send, it is unclear whether A’s counter party intends to send or receive New Orders.
>
> I would define the basic functionality as follows:
>
> “The Logon can be used to specify the message types supported during on a sending and receiving basis. In the logon message, the user may provide a list of valid supported application message types and the associated supported direction. The value of the send/receive flag in field 385, MsgDirection, is to be interpreted from the logon receiver’s point of view. (e.g. an incoming logon with a New Order indicated as receive denotes that the counterparty intends to send New Orders.) If this repeating group does not exist, then all messages are assumed to be valid per bilateral agreement.”
>
> Unfortunately the 4.2 spec does not address how the acceptor should respond to the initiator’s list of allowed message types. Should the acceptor echo back the list to the initiator? With this approach, the acceptor is bound by the initiator’s wishes. Is the acceptor allowed to respond with a different list of allowed message types? If the acceptor responds with a different list of allowed messages, how are conflicts resolved? Is the list of allowed messages for the session defined as the set of messages in the union of the acceptor’s and the initiator’s allowed lists or in the intersection? In some cases, the initiator may not provide a list of valid messages at all, but the acceptor may respond with one. In this case, the union approach appears to make sense. If the initiator provides a list of supported messages, then one might assume that the initiator has provided a complete list. Therefore there is no need for the acceptor to echo back the list of valid messages, unless the acceptor wished to provide a shortened list. In this case, the intersection approach appears to make sense. The NEON solution attempts to be as flexible as possible. When running as the initiator, we use the intersection. When running as the acceptor, we respond by echoing back the initiator’s list of valid message types. I would be very interested in hearing from other venders concerning how they have approached this problem.
>
> 2. The use of field 35, MsgType, in the logon message is problematic. In the “Field Definitions” section of the FIX.4.2 specification, field 35 is clearly defined. It can take on the value of ANY FIX message type, including administrative message types. Is it legal to include a heartbeat message in the list of legal messages? Is required include to heartbeat message in the list of legal messages? The intended use of field 35 is clear, it applies to application messages. However, from my point of view, it is only a matter of time before a client will encounter another’s vendor’s engine that implements a literal interpretation of the spec.
>
> Proposed solution:
> Define a new field, AppMsgType.
> AppMsgType = {the set of all message types} - {the set of all administrative message types}
> Use AppMsgType in place of MsgType.
>
> This solution removes all possibility of interpretation problems.
>
> I have one additional comment related to the use of field 35 in the logon message. The introduction of a field that is used in two distinctly different contexts can negatively effect the existing data structures used to hold the data from a FIX message. Till now, FIX message definitions have not had a single field used multiple times. Please note that fields in repeating structures appear multiple times, but within a single context. If a single field can be used in the message in multiple contexts, then data structures have to be rewritten to retrieved data based not only on repeat count and field Id, but also on context. I imagine many engines have been heavily optimized to retrieve field data only on field Id and, optionally, repeat count.
>
> Thanks,
>
- This is send or receive from the perspective of the one sending the message. Thus if I am a buyside firm, I might specify 384=16|35=0|385=R|35=1|385=R|35=2|385=R|35=3|385=R|35=4|385=R|35=5|385=R|35=A|385=R|35=6|385=R|35=8|385=R|35=0|385=S|35=1|385=S|35=2|385=S|35=3|385=S|35=4|385=S|35=5|385=S|35=A|385=S| This would indicate that I can receive all of the admin messages, plus IOIs (35=6) and ExecRpt (35=8) and that I can send all of the admin messages. When receiving a Logon message with this specified, think of it as "this is what my counterparty has told me they support". Note this is the opposite of your suggested language. I agree that clarification should be added via an Errata.
If one sends a Logon message with the supported MsgTypes repeating group specified, they should specify this from their point of view and according to their capabilities. Thus you do not echo back their values on your Logon response, rather would send your values.
The FIX spec does not directly address what to do if one is capable of receiving and the other is not capable of sending, etc. The Logon message simply gives you the ability to "know" and you can then define any actions to be taken.
Remember this is new (to 4.2), optional capability. It was added to facilitate dynamic configuration of client capabilities, etc.
- It should be the literal interpretation of field 35 (MsgType) and thus I think you should specify send/receive capability for the admin messages as well. You should be able to specify admin messages, business messages, and user defined messages. I don’t understand the drawback or problem to specifying the admin ones as well and don’t see the need for the new field you are suggesting.
re: "Till now, FIX message definitions have not had a single field used multiple times". I agree the fact that MsgType is in both the header and the body for the message is a mistake and a problem for parsers. It should have been 372 RefMsgType (same values as MsgType) in the repeating group of the Logon.
> I have a few concerns with the usage of the repeating group beginning with field 384, NoMsgTypes, in the logon message.
>
> 1. The meaning of field 385, MsgDirection, is ambiguous. Field 385 has valid values of “S” or “R” for send and receive respectively. However, the FIX.4.2 specification does not define send and receive with respect to a particular party. For example, if party A receives a logon with New Order marked as send, it is unclear whether A’s counter party intends to send or receive New Orders.
>
> I would define the basic functionality as follows:
>
> “The Logon can be used to specify the message types supported during on a sending and receiving basis. In the logon message, the user may provide a list of valid supported application message types and the associated supported direction. The value of the send/receive flag in field 385, MsgDirection, is to be interpreted from the logon receiver’s point of view. (e.g. an incoming logon with a New Order indicated as receive denotes that the counterparty intends to send New Orders.) If this repeating group does not exist, then all messages are assumed to be valid per bilateral agreement.”
>
> Unfortunately the 4.2 spec does not address how the acceptor should respond to the initiator’s list of allowed message types. Should the acceptor echo back the list to the initiator? With this approach, the acceptor is bound by the initiator’s wishes. Is the acceptor allowed to respond with a different list of allowed message types? If the acceptor responds with a different list of allowed messages, how are conflicts resolved? Is the list of allowed messages for the session defined as the set of messages in the union of the acceptor’s and the initiator’s allowed lists or in the intersection? In some cases, the initiator may not provide a list of valid messages at all, but the acceptor may respond with one. In this case, the union approach appears to make sense. If the initiator provides a list of supported messages, then one might assume that the initiator has provided a complete list. Therefore there is no need for the acceptor to echo back the list of valid messages, unless the acceptor wished to provide a shortened list. In this case, the intersection approach appears to make sense. The NEON solution attempts to be as flexible as possible. When running as the initiator, we use the intersection. When running as the acceptor, we respond by echoing back the initiator’s list of valid message types. I would be very interested in hearing from other venders concerning how they have approached this problem.
>
> 2. The use of field 35, MsgType, in the logon message is problematic. In the “Field Definitions” section of the FIX.4.2 specification, field 35 is clearly defined. It can take on the value of ANY FIX message type, including administrative message types. Is it legal to include a heartbeat message in the list of legal messages? Is required include to heartbeat message in the list of legal messages? The intended use of field 35 is clear, it applies to application messages. However, from my point of view, it is only a matter of time before a client will encounter another’s vendor’s engine that implements a literal interpretation of the spec.
>
> Proposed solution:
> Define a new field, AppMsgType.
> AppMsgType = {the set of all message types} - {the set of all administrative message types}
> Use AppMsgType in place of MsgType.
>
> This solution removes all possibility of interpretation problems.
>
> I have one additional comment related to the use of field 35 in the logon message. The introduction of a field that is used in two distinctly different contexts can negatively effect the existing data structures used to hold the data from a FIX message. Till now, FIX message definitions have not had a single field used multiple times. Please note that fields in repeating structures appear multiple times, but within a single context. If a single field can be used in the message in multiple contexts, then data structures have to be rewritten to retrieved data based not only on repeat count and field Id, but also on context. I imagine many engines have been heavily optimized to retrieve field data only on field Id and, optionally, repeat count.
>
> Thanks,
>