[Quickfix-developers] OrigSendingTime, sendingtime and MaxLatency

[Jain, A. <Ani...@rb...>]

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.