[This message was posted by Greg Wood of Credit Suisse <[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/c65e1b78 - PLEASE DO NOT REPLY BY MAIL.]
Hi Mark, My advice is based on pragmatism based on several years supporting clients trading global 24 hour Futures + FX markets, rather than strict adherence to the FIX spec regarding 24 hour support. You are quite correct to reset sequence numbers daily. Even resetting weekly leads to a lot of bloat and it makes things more difficult to identify all messages for a single day in the event of requiring replays, etc. Identify a nominal end of day. For most markets, this is just after 5pm New York time when trade dates roll from T to T+1 for overnight sessions. For 24 hour trading in Australia this is 5pm Sydney time. Use this to determine a suitable time for resetting sequence numbers or any maintenance time that you require. A simple sequence number reset between counterparties requires no down time but might cause a race condition if there is clock skew between counterparties. If you need to drop and reconnect sessions then try to set the window to as small a time as possible. I suggest that one party has a slightly smaller window defined so that when the other party reconnects, the first party is ready to receive the new session. Use this time to perform your maintenance such as reloading configurations, rolling log files, etc. You will find that most listed markets will have a small window themselves where products do not trade. On some bigger markets there might be staggered trading sessions across multiple products that make it difficult to find a time to recycle when nothing trades. Again, be pragmatic and identify the major products that you *must* be available for. If everything trades 24 hour (like global FX markets) then be pragmatic and go for the time when liquidity is lowest, again typically just after 5pm New York. One final point. Watchout for any persistence issues across a session recycle. You obviously don't want to lose control of an order working across a recycle. This is generally not an issue with commercial FIX engines but it is worth testing this scenario before going fully live. Hope this helps. Regards, - Greg > Is anyone able to provide some advice as to servicing a 24hr market. > > At present we are planning on ensuring our FIX implementation follows > the 24hr sequence reset rules as specified in the FIX Spec Vol 2 Session > Protocol section. > > In my case the client is the initiator and I am the acceptor. > > I have a few questions: > > 1. In the 24hr case, should NextExpectedMsgSeqNum be used to ensure > there are no race conditions between when the recommended test > request / heartbeat is sent and then the logon msg ( with > ResetSeqNumFlag=Y ) is sent? > > 2. If we need to do some house keeping around the session reset ( e.g > archive old orders, roll logs , clear some caches etc ), would it be > ok to perform these tasks following the successful logon msg ( with > ResetSeqNumFlag=Y ) from the client. > > 3. In fact in the 24hr environment, what is the recommended approach to > handle session housekeeping ( We need to do this so will don't bloat > out a system with large numbers of old orders living until the whole > system does a weekly reset for example) > > Any comments appreciated? [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 -~----------~----~----~----~------~----~------~--~---
