[This message was posted by John Prewett of Lava Trading <[email protected]> to the "4.4 Changes" discussion forum at http://fixprotocol.org/discuss/17. You can reply to it on-line at http://fixprotocol.org/discuss/read/fcde5231 - PLEASE DO NOT REPLY BY MAIL.]
Let me just clarify one point: Enabling TCP_NODELAY needs to be done on both ends of a TCP session in order to be effective. If only one side of a TCP session enables it, there will probably still be some nasty FIX latencies. This can be problematic if you enable TCP_NODELAY on "your" end but have no control over the "other" end. A "desperate times need desperate measures" approach to this issue if you cannot get the other end to enable TCP_NODELAY is to disable DelayedAck on "your" end NIC card. This will affect all TCP usage on that NIC card and isn't settable on a per-TCP session basis (on any operating system I have seen). You will then have solved the latency issue by only touching one end, but there will be many TCP ack-only runt packets now appearing on your network, one for each TCP packet received by your NIC. This approach is not recommended. It is not for the faint-of-heart. It can get you out of a problem, provided it doesn't upset the other TCP sessions (or even the problematic one) using that NIC. JohnP [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 -~----------~----~----~----~------~----~------~--~---
