[This message was posted by Danilo Silveira of Greenline Financial Technologies <[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/fd04166b - 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 Thank you very much JohnP, great help sir. [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 -~----------~----~----~----~------~----~------~--~---
