[Quickfix-developers] OrigSendingTime, sendingtime and MaxLatency
Brought to you by:
orenmnero
|
From: Jain, A. <Ani...@rb...> - 2005-10-03 15:19:10
|
Hi, As per the mail thread 'OrigSendingTime' (http://sourceforge.net/mailarchiv= e/forum.php?thread_id=3D8307323&forum_id=3D103), Oren Miller implies that, = as per FIX specs: OrigSendingTime, if data is not available, is set to same value as Sending= Time. However, once our connection went down as the Island server on the other en= d had problems. On resumption, we got back execution reports that had ident= ical SendingTime and OrigSendingTime, and reflected the actual trading situ= ation (and not this particular connection server's issues). It seems, the o= ffending server upon normalcy sent all the pending reports without modifyin= g the SendingTime. My question is: Will it not it be more useful to have MaxLatency logic chec= k difference between SendingTime and OrigSendingTime when both are availabl= e AFTER it checks difference between 'now' and SendingTime and finds it exc= eeds latency time. This will not affect most regular transactions, but will= 'understand' resumption from delays from the other side.=20 Maybe I can override Session::next behavior in FromApp? - I have not explor= ed. Thanks for your time. Anil Jain =20 -----Original Message----- From: qui...@li... [mailto:qui...@li...]On Behalf Of Oren Miller Sent: Monday, September 26, 2005 11:24 AM To: Alexey Zubko; qui...@li... Subject: Re: [Quickfix-developers] OrigSendingTime QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/html/ind= ex.html QuickFIX Support: http://www.quickfixengine.org/services.html It is conditionally required in the case that a message is resent: 122 OrigSendingTime N Required for message resends. If data is not availabl= e=20 set to same value as SendingTime (Can be embedded within encrypted data=20 section.) ----- Original Message -----=20 From: "Alexey Zubko" <ale...@in...> To: <qui...@li...> Sent: Monday, September 26, 2005 10:12 AM Subject: [Quickfix-developers] OrigSendingTime > QuickFIX Documentation:=20 > http://www.quickfixengine.org/quickfix/doc/html/index.html > QuickFIX Support: http://www.quickfixengine.org/services.html > > Hello, > > I have a question regarding processing of duplicated messages. > As I understand from the FIX (4.0) documentation the OrigSendingTime is=20 > not a required field. > But QF generates a rejection message anyway. > See the code below (last QF version): > > bool Session::doPossDup( const Message& msg ) > { QF_STACK_PUSH(Session::doPossDup) > > const Header & header =3D msg.getHeader(); > OrigSendingTime origSendingTime; > SendingTime sendingTime; > MsgType msgType; > > header.getField( msgType ); > header.getField( sendingTime ); > > if ( msgType !=3D MsgType_SequenceReset ) > { > if ( !header.isSetField( origSendingTime ) ) > { > generateReject( msg, 1, origSendingTime.getField() ); > return false; > } > header.getField( origSendingTime ); > > if ( origSendingTime > sendingTime ) > { > generateReject( msg, 10 ); > generateLogout(); > return false; > } > } > return true; > > QF_STACK_POP > } > > --=20 > > Regards, > Alexey Zubko > > Infinium Capital Corporation > (416) 360-7000 ext. 305 > ___________________________________________________________________________= _______________________________________________________ This E-Mail (including any attachments) may contain privileged or confident= ial information. It is intended only for the addressee(s) indicated above. The sender does not waive any of its rights, privileges or other protection= s respecting this information. =20 Any distribution, copying or other use of this E-Mail or the information it= contains, by other than an intended recipient, is not sanctioned and is pr= ohibited. If you received this E-Mail in error, please delete it and advise the sende= r (by return E-Mail or otherwise) immediately. This E-Mail (including any attachments) has been scanned for viruses.=20 It is believed to be free of any virus or other defect that might affect an= y computer system into which it is received and opened.=20 However, it is the responsibility of the recipient to ensure that it is vir= us free.=20 The sender accepts no responsibility for any loss or damage arising in any = way from its use. E-Mail received by or sent from RBC Capital Markets is subject to review by= Supervisory personnel.=20 Such communications are retained and may be produced to regulatory authorit= ies or others with legal rights to the information. |