Re: [Quickfix-developers] Apparent session logout logic problem
Brought to you by:
orenmnero
Menu
▾
▴
Re: [Quickfix-developers] Apparent session logout logic problem
|
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)
|
