[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/f88dc965 - PLEASE DO NOT REPLY BY MAIL.]
Hi again Mark, We see both scenarios with clients trading 24x5 with Credit Suisse but option 1 is by far the most popular for both parties. Some clients use option 2 for personal preference, but even in that case we tend to have an agreed mutual reset time so that the control is not completely in the hands of the client. To use the word pragmatism again, look at what you need to do. Housekeeping like rotating logs has the least impact and could be scheduled at midnight or 5pm, but reloading configurations to add new clients might have more impact, especially if you are loading multiple clients in one go. Are you servicing many clients with the same engine. Are you reloading configurations on a per client basis or using a daily maintenance window to handle all changes in a standard, scheduled manner. Are you relying on only doing upgrades and patches at the weekend rather than anything intra-week even in the case of an emergency. Do you have downstream systems that have their own maintenance windows. Etc, etc. I would say that most commercial engines allow all of this flexibility but how you apply this is up to how you decide to manage your environment and your sanity. In terms of clients, you'll find that a large number have their own maintenance windows and will accept some down time. You can then cater for the rest as an exception to the general rule and treat them accordingly. Perhaps you run a few different engines with particular schedules and you allocate clients according to their needs. It's a challenge to manage a 24 hour environment. I wish there were simple answers to all of these questions, but in real life it is very difficult to find a single fit for both clients and providers. And most clients understand this. Regards, - Greg > 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 -~----------~----~----~----~------~----~------~--~---
