[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/6ac76177 - PLEASE DO NOT REPLY BY MAIL.]
> Hi all, > > This is more a QuickFIX implementation doubt than a FIX doubt. Anyone > has experienced problems with disabling this QuickFIX socket option? I'm > having a problem that the messages are delaying to be acknowledged. And > I need to figure out where is the bottleneck. > > Thoughts? Under most "normal" scenarios, using setsockopt to enable TCP_NODELAY is a very good idea for FIX TCP sessions (no matter whether it is QuickFIX or not). There is an implication of a double-negative in your question, so I'm not exactly sure which way you are going from/to. Using a TCP FIX session without TCP_NODELAY enabled can cause occasional delays of up to 500mSec depending on the traffic patterns. I would recommend that most TCP FIX sessions use TCP_NODELAY enabled. The possible exception to this might be ultra high speed continuous message streaming such as market data where using TCP_NODELAY enabled could cause many "runt" packets which could conceivably make latency worse. In general, use TCP_NODELAY enabled for best TCP FIX performance. I hope this helps. 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 -~----------~----~----~----~------~----~------~--~---
