Hole in FIX protocol

, ,
1

Imported from previous forum

2

Hi all,

I am having this scenario that I am starting to think there is a loop hole in the protocol itself…

  1. Initiator send a Logon message with MsgSeqNum=30
  2. Acceptor reply (1) with a Logon message with MsgSeqNum=45
  3. Initiator reply (2) with a ResendRequest with MsgSeqNum=31, BeginSeqNum=1
  4. Acceptor send a TestRequest with MsgSeqNum=46 (The acceptor basically send this message right after the logon msg)
  5. Initiator reply (4) with a ResendRequest with MsgSeqNum=32, BeginSeqNum=1
  6. Acceptor reply (3) a GapFill with MsgSeqNum=1, NewSeqNum=47
  7. Acceptor send a TestRequest with MsgSeqNum=47
  8. Initiator reply (7) with a HeartBt message with MsgSeqNum=33
    9, Acceptor reply (5) a GapFill with MsgSeqNum=1, NewSeqNum=48
    …now, here is the problem. From the initiator’s point of view, the next expected number should be 48, but the received number from the GapFill message is 1, hence a logout is initiated.

The sessions initiated afterwards will have a similiar problem and no automatic solution could be done to solve this. Can anyone have any advice on this? Thanks.

3

[ original email was from Dennis Wiatzka - dennis.wiatzka@computershare.com ]
> Hi all,

I am having this scenario that I am starting to think there is a loop
hole in the protocol itself…

  1. Initiator send a Logon message with MsgSeqNum=30
  2. Acceptor reply (1) with a Logon message with MsgSeqNum=45
  3. Initiator reply (2) with a ResendRequest with MsgSeqNum=31,
    BeginSeqNum=1
  4. Acceptor send a TestRequest with MsgSeqNum=46 (The acceptor basically
    send this message right after the logon msg)
  5. Initiator reply (4) with a ResendRequest with MsgSeqNum=32,
    BeginSeqNum=1
  6. Acceptor reply (3) a GapFill with MsgSeqNum=1, NewSeqNum=47
  7. Acceptor send a TestRequest with MsgSeqNum=47
  8. Initiator reply (7) with a HeartBt message with MsgSeqNum=33 9,
    Acceptor reply (5) a GapFill with MsgSeqNum=1, NewSeqNum=48 …now,
    here is the problem. From the initiator’s point of view, the next
    expected number should be 48, but the received number from the
    GapFill message is 1, hence a logout is initiated.

The sessions initiated afterwards will have a similiar problem and no
automatic solution could be done to solve this. Can anyone have any
advice on this? Thanks.

In this scenario the Initiator should not have sent the second resend request. Once the first resend request has been sent the Initiator should ignore messages that do not have MsgSeqNum=1 (e.g.- TestRequest with MsgSeqNum=46) unless they are a Sequence Reset - Reset (as opposed to a Sequence Reset - Gap Fill which must have MsgSeqNum=1).

4

Hi,

Thanks for your reply. However would you mind telling me where in the 4.2/4.4 spec have this requirement? It seems from the protocol itselfs that the initator should always respond to any incoming message as long as it passes the validity check (ie. body length/checksum). In this case, the response would be a ResendRequest since it failed the SeqNumCheck.

Thanks,
Calvin

In this scenario the Initiator should not have sent the second resend
request. Once the first resend request has been sent the Initiator
should ignore messages that do not have MsgSeqNum=1 (e.g.- TestRequest
with MsgSeqNum=46) unless they are a Sequence Reset - Reset (as opposed
to a Sequence Reset - Gap Fill which must have MsgSeqNum=1).

5

[ original email was from Dennis Wiatzka - dennis.wiatzka@computershare.com ]
> Hi,

Thanks for your reply. However would you mind telling me where in the
4.2/4.4 spec have this requirement? It seems from the protocol itselfs
that the initator should always respond to any incoming message as long
as it passes the validity check (ie. body length/checksum). In this
case, the response would be a ResendRequest since it failed the
SeqNumCheck.

Thanks, Calvin

On page 7 of the FIX 4.4 specification the following recommendations are made:

- It is recommended to wait a short period of time following the Logon or to send a TestRequest and wait for a response to it before sending queued or new messages in order to allow both sides to handle resend request processing.  Failure to do this could result in a ResendRequest message being issued by one’s counterparty for each queued or new message sent.  (see "Logon Message NextExpectedMsgSeqNum Processing" for an alternative approach)

- It is also recommended that an engine should store out of sequence messages in a temporary queue and process them in order when the gap is closed. This prevents generating resend requests for n->m, n->m+1, n->m+2, ... which can result in many resent PossDupFlag=Y messages.

Thus -

  1. If the Resend Request was 1 through infinity the application must recognize that there may be messages in the pipe and trust that the messages which are ignored will be resent if they are business or gap filled if they are session.
  2. If the Resend Request was 1 through 45 the application must safe store messages in the pipe and process them only after the Resend Request has been honoured. (This applies to TestRequest with MsgSeqNum=46 since it followed, in sequence, after the logon with MsgSeqNum=45)

Ultimately the simplest solution is to wait a short period of time after the Logon processing before sending anything other than a Resend Request (the FIX 4.4 spec’s first recommendation).

Cheers

6

Hi all,

I am having this scenario that I am starting to think there is a loop
hole in the protocol itself…

  1. Initiator send a Logon message with MsgSeqNum=30
  2. Acceptor reply (1) with a Logon message with MsgSeqNum=45
  3. Initiator reply (2) with a ResendRequest with MsgSeqNum=31,
    BeginSeqNum=1
  4. Acceptor send a TestRequest with MsgSeqNum=46 (The acceptor basically
    send this message right after the logon msg)
  5. Initiator reply (4) with a ResendRequest with MsgSeqNum=32,
    BeginSeqNum=1
  6. Acceptor reply (3) a GapFill with MsgSeqNum=1, NewSeqNum=47
  7. Acceptor send a TestRequest with MsgSeqNum=47
  8. Initiator reply (7) with a HeartBt message with MsgSeqNum=33 9,
    Acceptor reply (5) a GapFill with MsgSeqNum=1, NewSeqNum=48 …now,
    here is the problem. From the initiator’s point of view, the next
    expected number should be 48, but the received number from the
    GapFill message is 1, hence a logout is initiated.

The sessions initiated afterwards will have a similiar problem and no
automatic solution could be done to solve this. Can anyone have any
advice on this? Thanks.

According to the protocol, all SequenceReset-GapFill(4) messages should be sent with the PossDupFlag set to “Y”. The protocol also indicates that all messages received with PossDup=Y must be inspected to determine if they are new or duplicates. Because the 1st GapFill message filled the sequence of messages from 1 to 48, the initiator will simply discard the 2nd GapFill message because it has a MsgSeqNum (1) that has already been received.