Imported from previous forum
[ original email was from Olexiy Getmanchuk - olexiyg@in4reach.com ]
Hello All,
Does someone know what should FIX engine do in such case (FIX spec is vague in respect to this):
- Received ResendRequest [35=2,7=1,36=0] and it happened that there is HUGE number of message to resend.
- Requester is processing resent messages without sending anything back (e.g. all resent messages are simply acks [35=8,39=0]).
- Because there is HUGE amound of messages to resent it happened that while resending them engine noticed that Requester have not sent any messages for more then heartbeat interval. According to spec it has to send TestRequest.
What is not clear is what seqNum (34) TestRequest should have?
E.g. if it happened between resending app messages (35=D) with seqNums(34) 100 and 101. Obviously engine cannot send TestRequest with seqNum=101 because 101 has already been assigned to message and cannot be reused. At the same time if we send TestRequest with seqNum=[lastSeqNumToResend+1] then it’ll be either ignored by counterparty or queied to be processed much later after last resent message get processed, or even can cause new ResendRequest. Also from the spec it is obvious that counterparty SHOULD NOT process any messages with seqNum higher then expected, even admin(session control) messages.
It seems that having an exclusion from the rules allowing TestRequests to be processed regardless of their seqNum(34) is not an option because sometimes FIX protocol relies on that (e.g. sending TestRequest before logging out in order to trigger ResendRequest).
Thanks,
Olexiy.
[ original email was from John Prewett - jprewett@lavatrading.com ]
Hi Olexiy,
Only after completing the resending of requested messages should you then start to process other incoming messages. You should not start to process the next message (TestRequest) until you have finished processing the previous message (ResendRequest).
JohnP
Hello All,
Does someone know what should FIX engine do in such case (FIX spec is
vague in respect to this):
- Received ResendRequest [35=2,7=1,36=0] and it happened that there is
HUGE number of message to resend.- Requester is processing resent messages without sending anything back
(e.g. all resent messages are simply acks [35=8,39=0]).- Because there is HUGE amound of messages to resent it happened that
while resending them engine noticed that Requester have not sent any
messages for more then heartbeat interval. According to spec it has
to send TestRequest.What is not clear is what seqNum (34) TestRequest should have?
E.g. if it happened between resending app messages (35=D) with
seqNums(34) 100 and 101. Obviously engine cannot send TestRequest
with seqNum=101 because 101 has already been assigned to message
and cannot be reused. At the same time if we send TestRequest with
seqNum=[lastSeqNumToResend+1] then it’ll be either ignored by
counterparty or queied to be processed much later after last resent
message get processed, or even can cause new ResendRequest. Also
from the spec it is obvious that counterparty SHOULD NOT process
any messages with seqNum higher then expected, even admin(session
control) messages.It seems that having an exclusion from the rules allowing TestRequests
to be processed regardless of their seqNum(34) is not an option because
sometimes FIX protocol relies on that (e.g. sending TestRequest before
logging out in order to trigger ResendRequest).Thanks, Olexiy.
[ original email was from Olexiy Getmanchuk - olexiyg@in4reach.com ]
Hi John,
Thanks for your reply and that part is rather clear in spec.
But my question was about a different thing. In other words, how should engines ON BOTH sides handle the situation when resending messages takes rather long time (e.g. more than 3*heartbeat interval) and counterparty did not sent any messages during heartbeat interval?
According to FIX spec in such case engine should send TestRequest but it doesn’t specify what seqNum it should have. We cannot specify TestRequest’s seqNum withing the range of requested messages. At the same time if TestRequest’s seqNum set to NextCorrectSeqNumBeforeResendRequest then the message should be queued and processed in proper order of SeqNums, which means that counterparty will not send Heartbeat so resender should disconnect the session.
Please correct me if I read FIX spec wrong.
Hi Olexiy,
Only after completing the resending of requested messages should you
then start to process other incoming messages. You should not start to
process the next message (TestRequest) until you have finished
processing the previous message (ResendRequest).JohnP
Hello All,
Does someone know what should FIX engine do in such case (FIX spec is
vague in respect to this):
- Received ResendRequest [35=2,7=1,36=0] and it happened that there
is HUGE number of message to resend.- Requester is processing resent messages without sending
anything back
(e.g. all resent messages are simply acks [35=8,39=0]).- Because there is HUGE amound of messages to resent it happened that
while resending them engine noticed that Requester have not sent
any messages for more then heartbeat interval. According to spec it
has to send TestRequest.What is not clear is what seqNum (34) TestRequest should have?
E.g. if it happened between resending app messages (35=D) with
seqNums(34) 100 and 101. Obviously engine cannot send TestRequest
with seqNum=101 because 101 has already been assigned to message
and cannot be reused. At the same time if we send TestRequest
with seqNum=[lastSeqNumToResend+1] then it’ll be either ignored
by counterparty or queied to be processed much later after last
resent message get processed, or even can cause new
ResendRequest. Also from the spec it is obvious that counterparty
SHOULD NOT process any messages with seqNum higher then expected,
even admin(session control) messages.It seems that having an exclusion from the rules allowing TestRequests
to be processed regardless of their seqNum(34) is not an option
because sometimes FIX protocol relies on that (e.g. sending
TestRequest before logging out in order to trigger ResendRequest).Thanks, Olexiy.
[ original email was from John Prewett - jprewett@lavatrading.com ]
Scenario:
Side A receives a ResendRequest from side B. The ResendRequest causes a massive number of messages to be resent which takes 3*Heartbeat interval.
Side A’s responsibility:
Side A should resend all requested messages. Only then should it start to process any other incoming messages. If there have been no messages received for a period greater than the heartbeat interval it should start the standard processing by sending a TestRequest. Should nothing be heard for a further reasonable interval, side A should send a logout message and disconnect. The fact that side A was unable to detect that side B had sent nothing for a longer time that usual (as side A was busy with resending messages for 3*heartbeat interval) isn’t a big issue.
If TCP is the underlying transport and side B had actually disconnected, this should have been detected during the massive resend. Should a disconnect be detected during the massive resend, the processing of the ResendRequest should be aborted and the remaining un(re)sent messages should no longer be attempted to be sent.
Side B’s responsibility:
Side B starts to receive a huge number of resent messages. It is still obligated to periodically send out heartbeat messsages. It could indeed elect to send application messages, but side A might not process them for quite a while. The fact that it is receiving a huge number of messages proves conclusively that side A is still alive and well.
Personally, I would seriously question the reason why a massive number of messages are being resent. If this is a regular occurrence, you may want to consider some other approach.
JohnP
Hi John,
Thanks for your reply and that part is rather clear in spec. But my
question was about a different thing. In other words, how should engines
ON BOTH sides handle the situation when resending messages takes rather
long time (e.g. more than 3*heartbeat interval) and counterparty did not
sent any messages during heartbeat interval?According to FIX spec in such case engine should send TestRequest but it
doesn’t specify what seqNum it should have. We cannot specify
TestRequest’s seqNum withing the range of requested messages. At the
same time if TestRequest’s seqNum set to
NextCorrectSeqNumBeforeResendRequest then the message should be queued
and processed in proper order of SeqNums, which means that counterparty
will not send Heartbeat so resender should disconnect the session.Please correct me if I read FIX spec wrong.
[ original email was from Olexiy Getmanchuk - olexiyg@in4reach.com ]
John,
Thanks a lot for your attention and reply. It seems like noone else care about guaranteed message delivery in FIX =)
Your reply’s part “Side A’s responsibility:” is exactly what I assumed from the spec but the problem is with this:
If there have been no messages received for a period greater than the
heartbeat interval it should start the standard processing by sending a
TestRequest. Should nothing be heard for a further reasonable interval,
side A should send a logout message and disconnect.
It’s not clear what seqNum should be used for that TestRequest. And that was mine original question. Can you elaborate your reply with example? When I tried it seems that FIX spec is controversial with respect to this use case (we cannot use seqNum from the resendRequest range and if we use (seqNum before ResendRequest)+1 then it’ll be processed much later and will cause side A to drop connection).
In part “Side B’s responsibility:” you have not covered how Side B should handle TestRequest which came with seqNum higher then expected.
Also I agre with you that this is not common situation these days but this might be easiliy happen to FIX routers or with algorithmic trading systems both with high frequency message exchange.
Thanks,
Olexiy.
Scenario: Side A receives a ResendRequest from side B. The
ResendRequest causes a massive number of messages to be resent which
takes 3*Heartbeat interval.Side A’s responsibility: Side A should resend all requested messages.
Only then should it start to process any other incoming messages. If
there have been no messages received for a period greater than the
heartbeat interval it should start the standard processing by sending a
TestRequest. Should nothing be heard for a further reasonable interval,
side A should send a logout message and disconnect. The fact that side A
was unable to detect that side B had sent nothing for a longer time that
usual (as side A was busy with resending messages for 3*heartbeat
interval) isn’t a big issue. If TCP is the underlying transport and side
B had actually disconnected, this should have been detected during the
massive resend. Should a disconnect be detected during the massive
resend, the processing of the ResendRequest should be aborted and the
remaining un(re)sent messages should no longer be attempted to be sent.Side B’s responsibility: Side B starts to receive a huge number of
resent messages. It is still obligated to periodically send out
heartbeat messsages. It could indeed elect to send application messages,
but side A might not process them for quite a while. The fact that it is
receiving a huge number of messages proves conclusively that side A is
still alive and well.Personally, I would seriously question the reason why a massive number
of messages are being resent. If this is a regular occurrence, you may
want to consider some other approach.JohnP
Hi John,
Thanks for your reply and that part is rather clear in spec. But my
question was about a different thing. In other words, how should
engines ON BOTH sides handle the situation when resending messages
takes rather long time (e.g. more than 3*heartbeat interval) and
counterparty did not sent any messages during heartbeat interval?According to FIX spec in such case engine should send TestRequest but
it doesn’t specify what seqNum it should have. We cannot specify
TestRequest’s seqNum withing the range of requested messages. At the
same time if TestRequest’s seqNum set to
NextCorrectSeqNumBeforeResendRequest then the message should be queued
and processed in proper order of SeqNums, which means that
counterparty will not send Heartbeat so resender should disconnect the
session.Please correct me if I read FIX spec wrong.
[ original email was from John Prewett - jprewett@lavatrading.com ]
You seem very confused, so my responses must not have been clear enough.
Let me try again.
When side A notices (AFTER finishing resending all requested messages) that side B has sent nothing for more that the heartbeat interval, side A sends out a TestRequest with the NEXT outgoing sequence number. This absolutely should not be out of sequence when side B receives it.
Example:
B has next send sequence number of 1.
B has next expected receive sequence number of 1.
A has next send sequence number of 1000000.
A has next expected receive sequence number of 1.
Numbers in parantheses are the MsgSeqNum of the message.
Resends either resend a gap fill or application message where appropriate.
Resends consolidate adjacent gap fills where appropriate.
A->logon(1000000)
B->logon(1)
B->ResendRequest(2) 1 thru infinity
A->resend of message(1)
A->resend of message(2)
…
A->resend of message(1000000)
[A notices that it has received nothing from B for more that heartbeat interval]
A->TestRequest (1000001)
Looking at your original question, I notice the following statement:
- Requester (B in my example) is processing resent messages without sending anything back (e.g. all resent messages are simply acks [35=8,39=0]).
This is a problem, B should still be sending heartbeats.
If this doesn’t clear it up, I will ask someone else to step up to the challenge as other duties are calling.
JohnP
John,
Thanks a lot for your attention and reply. It seems like noone else care
about guaranteed message delivery in FIX =)Your reply’s part “Side A’s responsibility:” is exactly what I assumed
from the spec but the problem is with this:If there have been no messages received for a period greater than the
heartbeat interval it should start the standard processing by sending a
TestRequest. Should nothing be heard for a further reasonable interval,
side A should send a logout message and disconnect.It’s not clear what seqNum should be used for that TestRequest. And that
was mine original question. Can you elaborate your reply with example?
When I tried it seems that FIX spec is controversial with respect to
this use case (we cannot use seqNum from the resendRequest range and if
we use (seqNum before ResendRequest)+1 then it’ll be processed much
later and will cause side A to drop connection).In part “Side B’s responsibility:” you have not covered how Side B
should handle TestRequest which came with seqNum higher then expected.Also I agre with you that this is not common situation these days but
this might be easiliy happen to FIX routers or with algorithmic trading
systems both with high frequency message exchange.Thanks, Olexiy.
[ original email was from Olexiy Getmanchuk - olexiyg@in4reach.com ]
> You seem very confused, so my responses must not have been clear enough.
I apologize, but it seems that you didn’t get the point of my question.
Let me try again.
When side A notices (AFTER finishing resending all requested messages)
In such case everything is clear. My question, again, is what side A should do if it has received nothing from side B for more then heartbeat interval in the MIDDLE of the resending, NOT AFTER finishing.
So, maybe it’ll be easer for you to think in terms of your example here is modified sequence of events with mark “???” for what is not clear from spec things:
Example:
B has next send sequence number of 1.
B has next expected receive sequence number of 1.
A has next send sequence number of 1000000.
A has next expected receive sequence number of 1.
Numbers in parantheses are the MsgSeqNum of the message.
Resends either resend a gap fill or application message where appropriate.
Resends consolidate adjacent gap fills where appropriate.
A->logon(1000000)
B->logon(1)
B->ResendRequest(2) 1 thru infinity
A->resend of message(1)
A->resend of message(2)
…
[heartbeat interval has expired and nothing was recieved by A from B, e.g. because of network disruption]
???// according to spec TestRequest should be sent out. But with what seqNum?
Looking at your original question, I notice the following statement:
- Requester (B in my example) is processing resent messages without
sending anything back (e.g. all resent messages are simply acks
[35=8,39=0]).
This is a problem, B should still be sending heartbeats.
It could be sending, but what if network problem happened at that time and that heartbeat was just lost?
If this doesn’t clear it up, I will ask someone else to step up to the
challenge as other duties are calling.JohnP
Thanks anyway for your time.
Hi Olexiy,
I think John has already provided the answer for your question regarding the “Before/After” problem. The answer was, the Party A should wait until it finishes its business (resending all application message) before sending the TestRequest message. Even though the timing of “Heartbt missing” is happening DURING the resending messages, it should still follow the queue instead of jumping up front to the sending queue, which is pre-occupied with the to-be-resend messages. If you think of the sending queue as FIFO, you will understand what John meant to say.
Cheers,
Calvin
[ original email was from Olexiy Getmanchuk - olexiyg@in4reach.com ]
Hi, Calvin,
Thanks for your attention to this question, but I cannot agree with you.
I just gave up to get an answer in this thread and started new one and got answer from Dennis Wiatzka (you can read his answer at http://fixprotocol.org/discuss/read/4e933f45).
I think what Dennis has suggested/explained is more in compliance with FIX protocol (fix-42-with_errata_20010501.pdf, page 26):
When either end of the connection has not received any data for (HeartBtInt +
“some reasonable transmission time”) seconds, it will transmit a Test Request message. If there is still
no Heartbeat message received after (HeartBtInt + “some reasonable transmission time”) seconds then
the connection should be considered lost and corrective action be initiated.
But I cannot find anything like what you said in FIX.4.2 spec.
Thanks.
Olexiy.
Hi Olexiy,
I think John has already provided the answer for your question regarding
the “Before/After” problem. The answer was, the Party A should wait
until it finishes its business (resending all application message)
before sending the TestRequest message. Even though the timing of
“Heartbt missing” is happening DURING the resending messages, it should
still follow the queue instead of jumping up front to the sending queue,
which is pre-occupied with the to-be-resend messages. If you think of
the sending queue as FIFO, you will understand what John meant to say.Cheers, Calvin
[ original email was from tushar deshpande - tushar.deshpande@citigroup.com ]
Olexiy,
what is the seqNum(tag 34) of the test-request sent by side-A? i thought that was also your question.
But in my example the problem is
that that TestRequest should be send in the middle of response to
ResendRequest (when you cannot issue new message with new seqNum) and
if you send ResendRequest with new seqNum (in my example it would be
9999999+1=10000000) then it should be processed according to its
seqNum and it’ll be late so side A should close socket (again
according to FIX spec).
Tushar
Hi, Calvin,
Thanks for your attention to this question, but I cannot agree with you.
I just gave up to get an answer in this thread and started new one and
got answer from Dennis Wiatzka (you can read his answer at
http://fixprotocol.org/discuss/read/4e933f45).I think what Dennis has suggested/explained is more in compliance with
FIX protocol (fix-42-with_errata_20010501.pdf, page 26):When either end of the connection has not received any data for
(HeartBtInt + “some reasonable transmission time”) seconds, it will
transmit a Test Request message. If there is still no Heartbeat message
received after (HeartBtInt + “some reasonable transmission time”)
seconds then the connection should be considered lost and corrective
action be initiated.But I cannot find anything like what you said in FIX.4.2 spec.
Thanks. Olexiy.
Hi Olexiy,
I think John has already provided the answer for your question
regarding the “Before/After” problem. The answer was, the Party A
should wait until it finishes its business (resending all application
message) before sending the TestRequest message. Even though the
timing of “Heartbt missing” is happening DURING the resending
messages, it should still follow the queue instead of jumping up front
to the sending queue, which is pre-occupied with the to-be-resend
messages. If you think of the sending queue as FIFO, you will
understand what John meant to say.Cheers, Calvin
[ original email was from Olexiy Getmanchuk - olexiyg@in4reach.com ]
Tushar,
I assume from the Dennis’s answer it has to be next seqNum before ResendRequest was received.
I.e. let’s suppose we had seqNum 1.000.000; next we received ResendRequest for messages [1,0] then during resending those messages should we need to send TestRequest it has to have seqNum=1.000.001
Olexiy,
what is the seqNum(tag 34) of the test-request sent by side-A? i thought
that was also your question.But in my example the problem is that that TestRequest should be send
in the middle of response to ResendRequest (when you cannot issue new
message with new seqNum) and if you send ResendRequest with new seqNum
(in my example it would be 9999999+1=10000000) then it should be
processed according to its seqNum and it’ll be late so side A should
close socket (again according to FIX spec).Tushar
Hi, Calvin,
Thanks for your attention to this question, but I cannot agree with
you. I just gave up to get an answer in this thread and started new
one and got answer from Dennis Wiatzka (you can read his answer at
http://fixprotocol.org/discuss/read/4e933f45).I think what Dennis has suggested/explained is more in compliance with
FIX protocol (fix-42-with_errata_20010501.pdf, page 26):When either end of the connection has not received any data for
(HeartBtInt + “some reasonable transmission time”) seconds, it will
transmit a Test Request message. If there is still no Heartbeat
message received after (HeartBtInt + “some reasonable transmission
time”) seconds then the connection should be considered lost and
corrective action be initiated.But I cannot find anything like what you said in FIX.4.2 spec.
Thanks. Olexiy.
Hi Olexiy,
I think John has already provided the answer for your question
regarding the “Before/After” problem. The answer was, the Party A
should wait until it finishes its business (resending all
application message) before sending the TestRequest message. Even
though the timing of “Heartbt missing” is happening DURING the
resending messages, it should still follow the queue instead of
jumping up front to the sending queue, which is pre-occupied with
the to-be-resend messages. If you think of the sending queue as
FIFO, you will understand what John meant to say.Cheers, Calvin
[ original email was from Ajay Kamdar - ajay.kamdar@thomson.com ]
FIX session layer management and application message processing are done in different logical layers in a typical FIX engine. Although the application layer in the FIX engine that issued the massive ResendRequest (Engine-A) might be busy processing all the messages resent by the counter party, its session layer should send out a heartbeat if no other application message has been sent out within the heartbeat interval. If Engine-A sends out a heartbeat as it should, then the FIX engine on the other side (Engine-B) that is resending the messages will not need to issue a TestRequest.
If for whatever reason Engine-B does need to issue a TestRequest while it is in the midst of resend a range of messages, the following example will hopefully make it clear what Engine-B should do:
- Say the sequence number of the last message Engine-B sent to Engine-A was 15664
- Engine-B receives a resend request from Engine-A to resend everything from 1 to infinity
- After having resent message sequence number 1000, Engine-B realizes it needs to issue a TestRequest
- Engine-B should send the TestRequest with sequence number 15665
- Engine-B should then continue processing the resend request, resending message sequence number 1001 onwards
- Ajay
[ original email was from Olexiy Getmanchuk - olexiyg@in4reach.com ]
Thanks Ajaj,
Please, find my comments bellow.
FIX session layer management and application message processing are done
in different logical layers in a typical FIX engine. Although the
application layer in the FIX engine that issued the massive
ResendRequest (Engine-A) might be busy processing all the messages
resent by the counter party, its session layer should send out a
heartbeat if no other application message has been sent out within the
heartbeat interval. If Engine-A sends out a heartbeat as it should, then
the FIX engine on the other side (Engine-B) that is resending the
messages will not need to issue a TestRequest.
I completely agree with you and this is clear in spec. But unfortunately there are a lot of engines out there and you cannot rely that all of them implemented that way. Also there might be some network disruption, which TestRequest should cover.
If for whatever reason Engine-B does need to issue a TestRequest while
it is in the midst of resend a range of messages, the following example
will hopefully make it clear what Engine-B should do:
- Say the sequence number of the last message Engine-B sent to Engine-
A was 15664- Engine-B receives a resend request from Engine-A to resend everything
from 1 to infinity- After having resent message sequence number 1000, Engine-B realizes it
needs to issue a TestRequest- Engine-B should send the TestRequest with sequence number 15665
- Engine-B should then continue processing the resend request, resending
message sequence number 1001 onwards
Sorry Ajaj, but you have not covered how Engine-A should process TestRequest which came with seqNum higher then expected (1001). According to FIX in such case engine should queue it internally and issue ResendRequest for 1001:15665, and then process it later. I.e. it means that Engine-A will not get reply to its TestRequest and have to disconnect.
Thanks,
Olexiy.
First, If the transport is a reliable connection oriented transport like TCP, in the scenario which ayou have described Heartbeat should not have been lost. So the question of sending a TestSendRequest from Engine-A does not arise.
Hearbeats can only be lost if it is a non reliable transport like UDP/multicast.
Second, Engine-B should not send mesages out of sequence (in this case TestSendRequest(1001+X) should not be sent before Message(1001)
Third, If Engine-B did send out of sequence (as it might be out of your control) then:
Engine-A should not process out of sequence TestRequest which came with seqNum higher than expected (1001).
OR
Engine-A should Queue up out of sequence TestSendRequest which came with seqNum higher than expected and Engine-A will time out and close the socket connection. Engine-A will then reconnect and same scenario will happen but it will utilmately get resolved as the range in TestResendRequest from Engine-A will adecrease with every connect/disconect/connect
OR
Engine-B should Queue up out of sequence TestSendRequest which came with seqNum higher than expected and send a ResendRequest for 1001:15665. THIS WOULD BE BAD as all the messages from 1001 which were asked to be resent by Engine-A in the first resendRequest would have to be retransmitted more than once or there might be an infinite loop (because Engine-A would then again send a Heartbeat and if the Heartbeat gets lost (which should not unless the transport is non reliable and connectionless) then misbehaving Engine-B which is sending out of sequence messages would sned a TestSendRequest and the Engine-B would athen again send a ResendRequest and this would go on as the initial set for ResendRequest was too large).
_sunny
Thanks Ajaj,
Please, find my comments bellow.
FIX session layer management and application message processing are
done in different logical layers in a typical FIX engine. Although the
application layer in the FIX engine that issued the massive
ResendRequest (Engine-A) might be busy processing all the messages
resent by the counter party, its session layer should send out a
heartbeat if no other application message has been sent out within the
heartbeat interval. If Engine-A sends out a heartbeat as it should,
then the FIX engine on the other side (Engine-B) that is resending the
messages will not need to issue a TestRequest.I completely agree with you and this is clear in spec. But unfortunately
there are a lot of engines out there and you cannot rely that all of
them implemented that way. Also there might be some network disruption,
which TestRequest should cover.If for whatever reason Engine-B does need to issue a TestRequest while
it is in the midst of resend a range of messages, the following
example will hopefully make it clear what Engine-B should do:
- Say the sequence number of the last message Engine-B sent to Engine-
A was 15664- Engine-B receives a resend request from Engine-A to resend
everything from 1 to infinity- After having resent message sequence number 1000, Engine-B realizes
it needs to issue a TestRequest- Engine-B should send the TestRequest with sequence number 15665
- Engine-B should then continue processing the resend request,
resending message sequence number 1001 onwardsSorry Ajaj, but you have not covered how Engine-A should process
TestRequest which came with seqNum higher then expected (1001).
According to FIX in such case engine should queue it internally and
issue ResendRequest for 1001:15665, and then process it later. I.e. it
means that Engine-A will not get reply to its TestRequest and have to
disconnect.Thanks, Olexiy.
[ original email was from Olexiy Getmanchuk - olexiyg@in4reach.com ]
Hello sunny,
Second, Engine-B should not send mesages out of sequence (in this case
TestSendRequest(1001+X) should not be sent before Message(1001)
Then what should Engine-B do?
Should it not to send TestRequest at all? Then it’ll contradict with FIX protocol.
If Engine-B does need to send TestRequest - then what seqNum should be assigned to TestRequest?
In any case, would you, please, point to the FIX spec section which supports your point of view.
-Olexiy.
Then what should Engine-B do? Should it not to send TestRequest at >>all?
I will try one more time
If Engine-B has not received any message from Engine-A, Engine-B should send TestRequest with Sequence Number
= #seq no of the last message pending in the outgoing Queue for this Session + 1
And this TestRequest from Engine-B should wait behind the pending outgoing list to Engine-A.
Nothing stops anybody to write bad code and send messages out of sequence from Engine-B to Engine-A in this case. If Engine-B does that then the protocol on the receiving side will handle that. This may result in a lot of retrasmissions on the wire between Engine-B and Engine-A for messages pending in the outgoing Queue in Engine-B for Engine-A or there might be an infinite loop of messages in the pending outgoing list being retransmiited from Engine-B to Engine-A again and again and Engine-A sending ResendRequest every time (As Engine-A is receiving requests out of order).
It could also happen that Engine-A may not send a ResendRequest on receiving out of sequence message send by Engine-B. Engine-A may just keep it aside wating for the Gap to be filled. If the out of sequence message is a TestRequest from Engine-B, Engine-B will time time out and close the connection. Engine-B will again connect to Engine-A and pending outgoing list in Engine-B for Engine-A will reduce. The above scenario will repeat for a number of times until the backlog in Engine-A will be zero eventually.
(Pending messages could be new messages in Engine-B bound for Engine-A or messages to be resent to Engine-A as Engine-A had asked for them to be resenta or both.)
_sunny
Hello sunny,
Second, Engine-B should not send mesages out of sequence (in this case
TestSendRequest(1001+X) should not be sent before Message(1001)Then what should Engine-B do? Should it not to send TestRequest at all?
Then it’ll contradict wi(th FIX protocol. If Engine-B does need to send
TestRequest - then what seqNum should be assigned to TestRequest?In any case, would you, please, point to the FIX spec section which
supports your point of view.-Olexiy.