Imported from previous forum
When I resend some message in response to the “ResendRequest”, I set the header field “PossDupFlag=Y”.
The problem is that the application recive this massege with new “MsgSeqNum” instead of the original…
Someone can help me…?
Thanks.
Hi Stefano,
When I resend some message in response to the “ResendRequest”, I set the
header field “PossDupFlag=Y”.
Normally the FIX engine takes care of the session protocol handling, e.g. answering ResendRequests. So what do you mean by “When I resend some messages”? Do you develop your own FIX engine? If not, which FIX engine do you use?
The problem is that the application recive this massege with new
“MsgSeqNum” instead of the original…
If the application (on the other side, I guess) receives it with a new MsgSeqNo, you must have sent it with that number. Or is the sending done by some other component.
Actually, I need some clarification about what your are doing. Currently, I guess you have a FIX engine and try to do part of its work, which should not be neccessary.
Cheers, Jörg
[ original email was from Witold Sames - wsames@yahoo.com ]
Stefano,
when receiving a resend request, the FIX engine should resend the messages asked for automatically if there are any available. In some cases you’ll find that some types of messages are NOT resent by some applications, such as administrative messages (you’ll receive a sequence reset gap fill message), or even some application messages such as IOIs and Advertisements.
However, the sequence numbers should not be new but represent the original message sequence numbers along with the PossDup flag (43) set to Y. The 97=Y is really meant to relay that an application (not the FIX engine) is resending messages; think “here’s some information I thibnk I sent to you, but in a new envelope”.
In brief, consider 43=Y the FIX engine’s job, and 97=Y the application’s job.
– Witold
Hi Stefano,
When I resend some message in response to the “ResendRequest”, I set
the header field “PossDupFlag=Y”.Normally the FIX engine takes care of the session protocol handling,
e.g. answering ResendRequests. So what do you mean by “When I resend
some messages”? Do you develop your own FIX engine? If not, which FIX
engine do you use?The problem is that the application recive this massege with new
“MsgSeqNum” instead of the original…If the application (on the other side, I guess) receives it with a new
MsgSeqNo, you must have sent it with that number. Or is the sending done
by some other component.Actually, I need some clarification about what your are doing.
Currently, I guess you have a FIX engine and try to do part of its work,
which should not be neccessary.Cheers, Jörg
I try to be more explicit.
I am developing a clien and a server both includes QuickFix engine.
My server application, store in a local database some application messages and resend them to the client only on “ResendRequest” by client.
When my server application intercept the ResendRequest, load the message from the database e send its to the client. So before resend this message I set PossDupFlag=Y (because is an application’s job).
The messages that I send has the original MsgSeqNum, but when I check this number on the client side, I find the MsgSeqNum replaced with another numeber in sequence with last MsgSeqNum that the client has recived and I don’t know why.
Stefano,
when receiving a resend request, the FIX engine should resend the
messages asked for automatically if there are any available. In some
cases you’ll find that some types of messages are NOT resent by some
applications, such as administrative messages (you’ll receive a sequence
reset gap fill message), or even some application messages such as IOIs
and Advertisements.However, the sequence numbers should not be new but represent the
original message sequence numbers along with the PossDup flag (43) set
to Y. The 97=Y is really meant to relay that an application (not the FIX
engine) is resending messages; think “here’s some information I thibnk I
sent to you, but in a new envelope”.In brief, consider 43=Y the FIX engine’s job, and 97=Y the
application’s job.– Witold
Hi Stefano,
When I resend some message in response to the “ResendRequest”, I set
the header field “PossDupFlag=Y”.Normally the FIX engine takes care of the session protocol handling,
e.g. answering ResendRequests. So what do you mean by “When I resend
some messages”? Do you develop your own FIX engine? If not, which
FIX engine do you use?The problem is that the application recive this massege with new
“MsgSeqNum” instead of the original…If the application (on the other side, I guess) receives it with a new
MsgSeqNo, you must have sent it with that number. Or is the sending
done by some other component.Actually, I need some clarification about what your are doing.
Currently, I guess you have a FIX engine and try to do part of its
work, which should not be neccessary.Cheers, Jörg
Hi Stefano,
I am developing a clien and a server both includes QuickFix engine. My
server application, store in a local database some application messages
and resend them to the client only on “ResendRequest” by client.When my server application intercept the ResendRequest, load the message
from the database e send its to the client. So before resend this
message I set PossDupFlag=Y (because is an application’s job).The messages that I send has the original MsgSeqNum, but when I check
this number on the client side, I find the MsgSeqNum replaced with
another numeber in sequence with last MsgSeqNum that the client has
recived and I don’t know why.
Ah, now I understand your context.
You are interfering with the FIX engines job. The QuickFIX engine takes care of the ResendRequests and answers them on their own. You should not answer ResendRequest in the application level and not set PossDup=Y there.
Do you think the QuickFIX would not do it? Or do you have a different requirement on the application level.
Please describe the reason why you want to answer ResendRequest in the application level.
Cheers, Jörg
Hi,
when I send from the client the “ResendRequest” like this:
8=FIX.4.2
9=76
35=2
34=3273
49=CLIENT
52=20060407-13:16:35.51
56=SERVER
7=1
16=0
10=018
I want recive all message from MsgSeqNum = 1 but the session level of QuickFIX sends nothing to the client.
I look in the quickFIX’s log in the server side and there are the message that the client has requested.
So I had thought about to implement the function in the application level.
Thanks…
Ah, now I understand your context.
You are interfering with the FIX engines job. The QuickFIX engine takes
care of the ResendRequests and answers them on their own. You should
not answer ResendRequest in the application level and not set
PossDup=Y there.Do you think the QuickFIX would not do it? Or do you have a different
requirement on the application level.Please describe the reason why you want to answer ResendRequest in the
application level.Cheers, Jörg
I want recive all message from MsgSeqNum = 1 but the session level of
QuickFIX sends nothing to the client.
Why do you want to receive all messages starting with MsgSeqNum = 1?
Jörg
It’s only an example… This is my think:
for many reasons the client side could require old messages… from one MsgSeqNum to another MsgSeqNum. The QuickFix engine do this only for his session operation and not every tme I ask this “service”
Stefano
I want recive all message from MsgSeqNum = 1 but the session level of
QuickFIX sends nothing to the client.Why do you want to receive all messages starting with MsgSeqNum = 1?
Jörg
It’s only an example… This is my think: for many reasons the client
side could require old messages… from one MsgSeqNum to another
MsgSeqNum. The QuickFix engine do this only for his session operation
and not every tme I ask this “service”
Any FIX session does this for the session operation. You get a stream of FIX messages with increasing numbers and without interruption from the engine on the application level. Under the hood the engine does its job to avoid gaps, re-request messages etc.
If you want to use this service, you are tweaking a specific engine. It may work, but it is completely outside the FIX spec. I suggest to go the QuickFIX list for this.
Cheers, Jörg
Ok, but in Fix specification there is written:
Upon receipt of a Resend Request, the resender can respond in one of three ways:
- retransmit the requested messages (in order) with the original sequence numbers and PossDupFlag set to “Y”
- issue a SeqReset-GapFill with PossDupFlag set to “Y” message to replace the retransmission of administrative and application messages
- issue a SeqReset-Reset with PossDupFlag set to “Y” to force sequence number synchronization
With QuickFix is not possible implemented the first point.
Stefano.
Any FIX session does this for the session operation. You get a stream of
FIX messages with increasing numbers and without interruption from the
engine on the application level. Under the hood the engine does its job
to avoid gaps, re-request messages etc.If you want to use this service, you are tweaking a specific engine. It
may work, but it is completely outside the FIX spec. I suggest to go the
QuickFIX list for this.Cheers, Jörg
[Stefano, I would like to move this discussion to the QuickFIX developers list. This would be the right place to discuss features of QuickFIX. Please post your questions there. Thanks, Jörg]
Ok, but in Fix specification there is written:
Upon receipt of a Resend Request, the resender can respond in one of
three ways:
- retransmit the requested messages (in order) with the original
sequence numbers and PossDupFlag set to “Y”- issue a SeqReset-GapFill with PossDupFlag set to “Y” message to
replace the retransmission of administrative and application messages- issue a SeqReset-Reset with PossDupFlag set to “Y” to force sequence
number synchronizationWith QuickFix is not possible implemented the first point.
QuickFIX can do full ResendRequest processing as mandated by the FIX specification. But this is hidden in the session level. If you want to access this from the application level, this is very engine specific.
Perhaps some other engine vendors could comment on this?
Cheers, Jörg