[This message was posted by Joseph Horowitz of AEGIS Software Inc. <[EMAIL PROTECTED]> to the "General Q/A" discussion forum at http://fixprotocol.org/discuss/22. You can reply to it on-line at http://fixprotocol.org/discuss/read/e16d2bb6 - PLEASE DO NOT REPLY BY MAIL.]
Mahesh, This is not a problem since we still consider the full round-trip time as a 'black box' value; therefore we know in our EMS when an execution venue or broker route is slow overall (network sniffers can also be used). It will be more than obvious and another route will be chosen. Thanks! -Joey > What if the counterparty FIX Driver does not provide the time it > received a message truly instead puts a time which "makes it look > faster"? as a developer, to make my FIX engine and Trading application > faster, I populate this new Tag RelatedRequestMessageReceiptTime (1427 > since 1426 is the last used tag number in FIX.5.0-SP1) as Sending time > (52) of my out message minus 10 milliseconds - so always my system would > appear to have 10 ms response time. > > Its the same logic like what Ryan stated "a system with slow business > logic might persuade their engine vendor to implement PI/PO messages in > the engine itself". There is no end to this kind of cheating. [You can unsubscribe from this discussion group by sending a message to mailto:[EMAIL PROTECTED] --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Financial Information eXchange" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/FIX-Protocol?hl=en -~----------~----~----~----~------~----~------~--~---
