Resends Again!

steveswift_x · July 13, 2001, 4:18pm

Imported from previous forum

steveswift_x · July 13, 2001, 4:18pm

Hello,

I have been reading all of the posts concerning resend protocols. I am writing this logic right now for our new FIX engine and I am a bit confused by all the differing views. Can anyone answer the following:

During a resend do you send new orders through
as you are doing a resend?
Do the Heartbeats get suspended during resend?
If you are responding to a resend request do
you stop accepting new transactions as you are
filling the resend request?
When you send a Gap Fill command what sequence
number do you put in the header? The next seq
number you would have sent under normal
conditions or anything since it is ignored?
Do some of you just Gap Fill the whole request
since it can be dangerous to send old orders,
cancels , etc. due to the market price could
have changed and you would be stuck to honor
the original price?

Any help would be great!

Steve

fplpo_x · July 13, 2001, 5:32pm

[ original email was from Danny Shobrook - danny@aptcompsys.com ]
Answers below:

>
> 1) During a resend do you send new orders through
> as you are doing a resend?

If you do the other engine should trigger new resend requests as these new orders are out of sequence. Our engine queues any new messages during a resend.

> 2) Do the Heartbeats get suspended during resend?

To quote from the FIX spec:
"When either end of a FIX connection has not sent any data for [HeartBtInt] seconds, it will transmit a Heartbeat message"

If you are performing a resend operation, you are obviously sending data so no new heartbeats.

However, you should be maintaining a timer for the other side - assuming logon has been completed.

> 3) If you are responding to a resend request do
> you stop accepting new transactions as you are
> filling the resend request?

Not unless the other side is out of sequence as well.

> 4) When you send a Gap Fill command what sequence
> number do you put in the header? The next seq
> number you would have sent under normal
> conditions or anything since it is ignored?

The sequence number of the next message to be sent. ie if you are resending from 10 to 15, with one gap fill at a time, then 10 would have new number 11, 11 would have 12 etc.

If you put the next sequence number as 15, then most engines will assume the gap has been filled and ignore the rest. However, I know of at least one engine that just barfs if try to do this.

> 5) Do some of you just Gap Fill the whole request
> since it can be dangerous to send old orders,
> cancels , etc. due to the market price could
> have changed and you would be stuck to honor
> the original price?

This is a business level decision. I know of one engine that always resends, based on the assumption that the poss dup flag will be checked at the other end - which is a pretty dangerous assumption. Ours on the other hand gives the opportunity to the application to veto resending a message, however this feature is not widely used - only two customers use it.

Danny

fplpo_x · July 13, 2001, 5:58pm

[ original email was from Himanshu Sharma - himanshu_sharma@rsco.com ]
> Hello,
>
> I have been reading all of the posts concerning resend protocols. I am writing this logic right now for our new FIX engine and I am a bit confused by all the differing views. Can anyone answer the following:
##FIX protocol requires that if any message is resent (retransmission of a message with same SeqNo), it should be sent with a flag PossDup=Y (tag 43), so that counterparty can recognize it. If your business-logic doesn’t want to resend orders (say the mkt is highly volatile for them), then FIX-Engine shouldn’t persist them. And FIX-Engine should resend only those message which are persisted by it. You should be carefull in what your FIX-Engine persist. If you don’t persist Orders, you shouldn decide whether to persist Modifications/Cancels. And you application side should be informed about every successful/unsuccessful transmission of Order/cancel/Modification to the counterparty.

>
> 1) During a resend do you send new orders through
> as you are doing a resend?
##New Orders should be send with new SeqNo.

> 2) Do the Heartbeats get suspended during resend?

Heartbeats should be only sent when you don’t have any other message to send.

> 3) If you are responding to a resend request do
> you stop accepting new transactions as you are
> filling the resend request?

You should accept new transactions while you are resending the messages. Accepting new transactions should be given preference (run in priority thread)?.

> 4) When you send a Gap Fill command what sequence
> number do you put in the header? The next seq
> number you would have sent under normal
> conditions or anything since it is ignored?

This message depends on the GapFillFlag.

If GapFillFlag is “N” or not sent at all, then MsgSeqNo in Header is ignored and NewSeqNum is the sequence number of the next outgoing message (for synchronization of SeqNum in the event of an application failure).If GapFillFlag=Y, then the MsgSeqNum in header should follow the SeqNum rules , i.e.
1.if you sending this GapFill in place of XX number of messages you don’t wanna “REsend”, then this MsgSeqNum in Header will be some old seq num and NewSeqNum will be the next expected outgoing seq num.
2.Or this MsgSeqNum is the next expected new outgoing seq num.

> 5) Do some of you just Gap Fill the whole request
> since it can be dangerous to send old orders,
> cancels , etc. due to the market price could
> have changed and you would be stuck to honor
> the original price?
##You can be flexible in this, based on the persistence of selective messages. In this way, it can be switched on/off anytime.
>
>
> Any help would be great!
>
> Steve
>

fplpo_x · July 13, 2001, 6:08pm

[ original email was from Nick Kopan - nkopan@attain.com ]
From your questions, I assume you are looking at this from the client side, though the logic is identical. See comments below:

> Hello,
>
> I have been reading all of the posts concerning resend protocols. I am writing this logic right now for our new FIX engine and I am a bit confused by all the differing views. Can anyone answer the following:
>
> 1) During a resend do you send new orders through
> as you are doing a resend?

Our ECN queues all messages when responding to a Resend Request.

> 2) Do the Heartbeats get suspended during resend?
> 3) If you are responding to a resend request do
> you stop accepting new transactions as you are
> filling the resend request?

If I understand correctly, you mean Execution Reports ("transactions"). Like Danny said, this is on the opposite stream.

> 4) When you send a Gap Fill command what sequence
> number do you put in the header? The next seq
> number you would have sent under normal
> conditions or anything since it is ignored?

The SequenceReset / GapFill message is classified by the GapFillFlag. If GapFillFlag is not present or set to ‘N’, then it is a sequence reset, and the sequence number is ignored and the gap is filled to NextSeqNo. If GapFillFlag is ‘Y’, then the sequence number must be checked, so the sender set the SeqNo of the GapFill to the first sequence number contained in the ResendRequest.

> 5) Do some of you just Gap Fill the whole request
> since it can be dangerous to send old orders,
> cancels , etc. due to the market price could
> have changed and you would be stuck to honor
> the original price?

You could either check the TransactTime / SendingTime of the "old" order, or you could compare the price to market prices (if you have this data easily accessible, very resource intensive though…)

It’s your decision, but most Fix client engines do not resend orders, just cancels. It is a business decision each client must make.

-Nick

>
>
> Any help would be great!
>
> Steve
>

fplpo_x · July 13, 2001, 6:13pm