[This message was posted by Mark Thomson of LC <[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/36510429 - PLEASE DO NOT REPLY BY MAIL.]
Thanks Greg, That's very helpful. I have a further question regarding wether I should let the client reset sequence numbers ( via the logon msg ) or I identify a window of opportunity. My market trades 24/5 and there is effectively no period when trading is not available. Hence I only have a few options: 1. Have an agreed time ( agreed by the client ) that sequence numbers will be reset. Disconnect the client, perform housekeeping and reset sequence numbers ( on a per session basis ) and wait for client to reconnect 2. Allow the client to reset their sequence numbers at any time of the trading day ( as long as it's done once per trading day ) via the re-issue of a logon message. In terms of simplicity Option 1 would be my pick. But it is likely my clients will wish to use option 2. In either case do i need to make sure my housekeeping is completed quickly ? I think there might be an issue if in the option 2 case I take more than a few seconds to complete any housekeeping > 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 -~----------~----~----~----~------~----~------~--~---
