Imported from previous forum
[ original email was from David Bradley - david.bradley@wanadoo.fr ]
I came across the following opportunity for improvement during my detailed examination of the FIX 4.4 spec.
I submit the suggestion for your consideration.
Sincerely,
David Bradley
Below is an extract from March 25, 2003 Fix 4.4 Volume 2 Page 7. (Section discussing the Session Protocol)
Quote…
- It is recommended to wait a short period of time following the Logon or to send a TestRequest and wait for a response to it before sending queued or new messages in order to allow both sides to handle resend request processing. Failure to do this could result in a ResendRequest message being issued by one’s counterparty for each queued or new message sent.
…End Quote.
The phrase "…wait a short period of time…" represents a protocol weakness that can be (and probably should be) addressed. I have faced and solved this issue in other messaging protocols before.
The motivation to solve it is the following:
- the amount to wait will be volume and bandwidth dependent. In other words the minimum amount of time to wait will vary according to:
- the amount of data being handled on other
connections by the accepting system and - by the type/quality of connection made by the initiator.
This means that "to be safe" the developer will have to grossly over estimate the minimum time or risk unreliable connection results.
-
Financial transactions are time critical. Intentionally adding delays while the technology providing bandwidth continues to improve will put users of a protocol implementation with fixed delays at a business disadvantage and demand periodic review of this delay by developers and the corresponding deployment expense if it is changed.
-
The benefit of the first change proposed will be to:
- shorten the time to create a FIX Connection by a significant
percentage of the total transaction submission time. - increase the robustness of applications using the protocol
- increase the leverage provided by the incremental
improvements in bandwidth available in the future.
The solution is not too difficult:
there are two similar methods. The first is the best.
- Each side includes (in the logon and logon acknowledgement messages) a tag specifying what it expects its next inbound sequence number to be.
In other words, the initiator adds a tag to its original logon request indicating what it expects the next inbound sequence number to be. This allows the acceptor to perform an inspection and determine if resynchronisation will be attempted by the other side.
In the other direction and more significantly, the acceptor includes what it thinks its next incoming seq should be in the acknowledgement Logon message sent back to the initiator. This allows the initiator to make its own determination about whether it can proceed immediately with new/queued messages or wait for resynchronisation. Note that for backward compatibility reasons, the acceptor should only add this tag if the initiator puts in the same tag as described. This allows older initiators to connect to newer acceptors.
2)The second method does the same thing but rather than burying the "next expected inbound sequence number" tag into the logon process, there is a separate, explicit exchange done after logon to achieve the same thing. Even though this method is definitely slower as it adds at least the round trip delay time for the message exchange, for compatibility purposes it may necessary.
I am not sure, however the sending of a "TestRequest" may achieve the result with the same efficiency as method 2). If this "lower grade" solution is selected it should be documented as either a required or highly recommended practice.
[ original email was from Kevin Houstoun - kevin.houstoun@ssmb.com ]
This has been assigned ID "[PC20030417_1] session protocol improvement" and will be discussed by the global technical committee.
> I came across the following opportunity for improvement during my detailed examination of the FIX 4.4 spec.
>
> I submit the suggestion for your consideration.
> Sincerely,
> David Bradley
>
> ---------------------------------
>
> Below is an extract from March 25, 2003 Fix 4.4 Volume 2 Page 7. (Section discussing the Session Protocol)
>
> Quote…
> * It is recommended to wait a short period of time following the Logon or to send a TestRequest and wait for a response to it before sending queued or new messages in order to allow both sides to handle resend request processing. Failure to do this could result in a ResendRequest message being issued by one’s counterparty for each queued or new message sent.
>
> …End Quote.
>
>
> The phrase "…wait a short period of time…" represents a protocol weakness that can be (and probably should be) addressed. I have faced and solved this issue in other messaging protocols before.
>
> The motivation to solve it is the following:
> ============================================
> 1) the amount to wait will be volume and bandwidth dependent. In other words the minimum amount of time to wait will vary according to:
> - the amount of data being handled on other
> connections by the accepting system and
> - by the type/quality of connection made by the initiator.
> This means that "to be safe" the developer will have to grossly over estimate the minimum time or risk unreliable connection results.
>
> 2) Financial transactions are time critical. Intentionally adding delays while the technology providing bandwidth continues to improve will put users of a protocol implementation with fixed delays at a business disadvantage and demand periodic review of this delay by developers and the corresponding deployment expense if it is changed.
>
> 3) The benefit of the first change proposed will be to:
> - shorten the time to create a FIX Connection by a significant
> percentage of the total transaction submission time.
> - increase the robustness of applications using the protocol
> - increase the leverage provided by the incremental
> improvements in bandwidth available in the future.
>
> The solution is not too difficult:
> ==================================
> there are two similar methods. The first is the best.
> 1) Each side includes (in the logon and logon acknowledgement messages) a tag specifying what it expects its next inbound sequence number to be.
>
> In other words, the initiator adds a tag to its original logon request indicating what it expects the next inbound sequence number to be. This allows the acceptor to perform an inspection and determine if resynchronisation will be attempted by the other side.
>
> In the other direction and more significantly, the acceptor includes what it thinks its next incoming seq should be in the acknowledgement Logon message sent back to the initiator. This allows the initiator to make its own determination about whether it can proceed immediately with new/queued messages or wait for resynchronisation. Note that for backward compatibility reasons, the acceptor should only add this tag if the initiator puts in the same tag as described. This allows older initiators to connect to newer acceptors.
>
> 2)The second method does the same thing but rather than burying the "next expected inbound sequence number" tag into the logon process, there is a separate, explicit exchange done after logon to achieve the same thing. Even though this method is definitely slower as it adds at least the round trip delay time for the message exchange, for compatibility purposes it may necessary.
>
> I am not sure, however the sending of a "TestRequest" may achieve the result with the same efficiency as method 2). If this "lower grade" solution is selected it should be documented as either a required or highly recommended practice.
>
>
>
>