TestRequest support

[ujos]

On one of the past projects I used TestRequest message to measure network latency between Trader and Exchange. Would be great to have such opportunity in FIXP as well.

[donmendelson]

In my view, any network latency measurement taken in an application is likely to be inaccurate. On the send side, the application has to read the system clock before sending the message, so it does not exactly represent the time that it is put on the wire. Conversely, on the receive side there can be a delay between network IO and the time that the application thread reacts to it and reads the clock.

It is better to use passive network taps or precision timestamping protocols for measuring network latency rather than application logic.

[ujos]

Session level messages on the server side can be processed very fast (10-20microseconds). If not, it is issue for investigation.

Network latency between Traders and Exchange usually is quite high - 300 microseconds if not collocation. So, latency added by software is negligible.

That is why I think it is good tool for preliminary investigation.

Also Test Request in the unit testing helps to ensure that server has received messages sent before Test Request.

[adkapur]

Something like a tracer message is more appropriate as an infrastructure message like NCSSR and is not really needed in FIXP per se

[donmendelson]

The consensus of the working group was to meet the requirement through other means rather than add a feature to the session protocol

[jimnup]

One last comment on this point - I am strongly in favor of not encumbering the session layer with features that may provide little value, but actually could obscure or obfuscate the desired understanding of behavior around timing and latency. What I would suggest is that if this is required at an application layer, let's say for something like order routing, maybe the use of an OrderStatusRequest would give sufficient information on a very, very questionable measure of round trip time. This round trip time that would result from and OrderStatusRequest may have some use for business operations personnel for traditional order routing for instance as long as the limitations in terms of resolution and accuracy are well understood and communicated. Users that really need this level of measurement likely have built out their own network latency measurement infrastructure.