Re: [Quickfix-developers] Apparent session logout logic problem
Brought to you by:
orenmnero
From: <OM...@th...> - 2002-07-11 15:59:32
|
Believe me, I absolutely see why it can be interpreted as such, but I do not believe it is clear (which the FIX spec rarely is). In most places that the FIX spec refers to session termination, they are refering to termination of the sessions connection, not an actual reset of the session itself. If you quote the full passage that you did in the previous message you can see this more clearly. "Normal termination of the message exchange session will be completed via the exchange of Logout messages. Termination by other means should be considered an abnormal condition and dealt with as an error. Session termination without receiving a Logout should treat the counterparty as logged out." Here they are saying that if the session is terminated, it should be treated as if the counter party logged out. Since there is no way to detect if the counterparty has reset their session out of the blue, it seems to me that session termination is synonymous with disconnection. Also they say that a termination without a logout message should be treated as if they had logged out. If logout behavior entailed resetting the session, that would indicate a session would be reset during normal and abnormal termination which I think we can both agree is not something we would want. In any case I can not agree that the passage above is clear and unambigous. There is also nothing that I can find in the protocol specifications session state matrix to indicate that sequence numbers are reset during logout. And as you indicated the other engine you are using has a setting so they have certainly run into others who have interpreted this passage differently from them. The FIX committee is currently working on the FIX 4.3 errata. I would be happy to forward them this issue so they can hopefully clarify their intention in the next document. In any case, as the other engine has wisely observed, if a configuration setting is added the point becomes moot. And since our code is open source, the point is even mooter (such a word? why not.) Best, --oren |---------+-----------------------------------------------> | | Gene Gorokhovsky | | | <mus...@ya...> | | | Sent by: | | | qui...@li...ur| | | ceforge.net | | | | | | | | | 07/11/2002 09:02 AM | | | | |---------+-----------------------------------------------> >----------------------------------------------------------------------------------------------| | | | To: qui...@li... | | cc: | | Subject: Re: [Quickfix-developers] Apparent session logout logic problem | >----------------------------------------------------------------------------------------------| I beg to disagree about what is FIX compliant and to your spec quote I have my spec counterquote (from 4.1 spec) "Logout - Normal termination of the message exchange session will be completed via the exchange of Logout messages. Termination by other means should be considered an abnormal condition and dealt with as an error" This to my view clearly indicates that session is to be terminated when logout is received, and therefore sequence can be reset not only on ResetSeqNumFlag. I believe that although session can exist across multiple TCP/IP (or other carrier protocol) connections, it cannot span past a Logout message. In the current QuickFIX interpretation Logout message serves absolutely no purpose except for message resync handshaking -- quote contrary to its name. I am attaching other vendors CFG file -- they have two settings to deal with logout: separately whether to reset session and whether to reset sequence, and the comments clearly indicate that in their opionion both session and sequence are to be reset on logout to be in spec compliance. Gene Gorokhovsky --- OM...@th... wrote: > > Gene, > > This is how FIX defines a session: > > "A FIX session is defined as a bi-directional stream > of ordered messages > between two parties within a continuous sequence > number series. A single > FIX session can exist across multiple physical > connections. Parties can > connect and disconnect multiple times while > maintaining a single FIX > session. Connecting parties must bi-laterally agree > as to when sessions are > to be started/stopped based upon individual system > and time zone > requirements. It is recommended that a new FIX > session be established once > within each 24 hour period. It is possible to > maintain 24 hour connectivity > and establish a new set of sequence numbers by > sending a Logon message with > the ResetSeqNumFlag set." > > But never fear. QuickFIX was designed to operate > with engines like the one > you describe. Simply add the following lines to your > onLogout method > callback: > > void onLogout( const FIX::SessionID& sessionID ) > { > FIX::Session* pSession = > FIX::Session::lookupSession(sessionID); > if(pSession) pSession->reset(); > } > > Now keep in mind that onLogout also gets called on a > hard disconnect, > because of another line in the spec ("Session > termination without receiving > a Logout should treat the counterparty as logged > out."). If the engine you > are connecting with is truly resetting with every > logon/logout pair and not > with abnormal disconnects, then you may want to move > the above code to the > fromAdmin callback and call it whenever you see a > Logout message pass > through. > > Since I have seen another engine that behaves in > this way (CME's ORAPI), it > may be a good idea to add a configuration setting > called > ResetSessionOnLogout or something. > > --oren > > > > |---------+-----------------------------------------------> > | | Gene Gorokhovsky > | > | | <mus...@ya...> > | > | | Sent by: > | > | | > qui...@li...ur| > | | ceforge.net > | > | | > | > | | > | > | | 07/11/2002 02:07 AM > | > | | > | > |---------+-----------------------------------------------> > > > ----------------------------------------------------------------------------------------------| > | > | > | To: > qui...@li... > | > | cc: > | > | Subject: [Quickfix-developers] Apparent > session logout logic problem | > > > ----------------------------------------------------------------------------------------------| > > > > > Please forgive me if I am wildly off the mark, but > should not the session be completely reset, > including > the target session num and file store, upon > receiving > a logout message? > I have been testing QuickFIX interoperability with > another engine using the ordermatch sample, and > their > test client keeps getting rejected on sessions after > the first one, because it resets the msgnum back to > 1 > after sending a valid logout, and QuickFIX does not > That another vendor, which I cannot disclose, keeps > separate message counters for every login/logout > pair. > In my view their approach corresponds better to FIX > specification, which clearly indicates that logout > message terminates session, nd therefore sequence > numbers ought to be restarted. > If I am right and this is indeed a problem, the > quick > and dirty way to change the behavior would be to > perform a Session::reset() instead of > Session::disconnect() when a logout message is > received. > > Gene Gorokhovsky > > > __________________________________________________ > Do You Yahoo!? > Sign up for SBC Yahoo! Dial - First Month Free > http://sbc.yahoo.com > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > PC Mods, Computing goodies, cases & more > http://thinkgeek.com/sf > _______________________________________________ > Quickfix-developers mailing list > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfix-developers > > > > __________________________________________________ Do You Yahoo!? Sign up for SBC Yahoo! Dial - First Month Free http://sbc.yahoo.com(See attached file: engine.properties) |