PossDup and PossResend queries

, ,
1

Imported from previous forum

2

Can someone please tell me what is the expected behavior from the broker when the broker receives (from the client) an Order Cancel/Replace Request (MsgType G) or an Order Cancel Request (MsgType F) with Tag 97 PossResend = ‘Y’ where the message is determined by the broker to be a duplicate. Should the broker send back a message to the client and if so what message? Or should the broker just ignore the order request and not send anything back to the client?

Can someone also please tell me what response is required from the broker when Tag 43 PossDup is set to ‘Y’ (and Tag 97 PossResend has not been provided) in a New Order Single, Replace Request and Cancel Request where the broker again has determined that the message is a duplicate?

3

Hi Mary,

PossDup and PossResend are two flavours of the same mechanism by which the client can re-send messages in the event the client “suspects” data loss.

In a nut-shell…

  1. Poss Dup - Means the client is re-sending a message with the same sequence number of the original.

  2. Poss Resend - Means the client is re-sending a message with a newly stamped sequence number

Both these methods are session level re-transmission options and are not specific to a particular message type (G in your case), and that it applies in general to any message.

Now coming to how one should handle both…

  1. Poss Dup - As the name conveys, is a duplicate. Its being re-sent by the client with the same sequence number. If your receiving application has already got this sequence number, then “just ignore”. Else update your system with that message. This can be concluded at the session level itself since the sequence number itself is enough to decide whether its a duplicate for the receiver indeed.

  2. Poss Resend - Its again re-transmission but with new sequence numbers. Hence, here to validate whether the message is a duplicate, sequence number is of no use. This validation should take place in the application layer. Hence this requires knowledge of the message type.
    The methods are…

For New(D) / Amend(G) / Cancel(F)- Validate whether the “Client Order ID” of the message in question is already received or not. If its a duplicate, then discard.

For Executions (8) - Validate the “ExecID” for duplicates.

In your case… (For G) if a client sends you a message with Pos Resend, validate the Client Order ID to see if its duplicate. If so, just drop it.

There is no requirement to convey any information on the acceptance of re-transmission. Its either take or discard.

Hope this helped you!

Best Regards,
Thaya.

Can someone please tell me what is the expected behavior from the broker
when the broker receives (from the client) an Order Cancel/Replace
Request (MsgType G) or an Order Cancel Request (MsgType F) with Tag 97
PossResend = ‘Y’ where the message is determined by the broker to be a
duplicate. Should the broker send back a message to the client and if so
what message? Or should the broker just ignore the order request and not
send anything back to the client?

Can someone also please tell me what response is required from the
broker when Tag 43 PossDup is set to ‘Y’ (and Tag 97 PossResend has not
been provided) in a New Order Single, Replace Request and Cancel Request
where the broker again has determined that the message is a duplicate?

4

Hi All,

Can someone please tell the scenario when a client has to resend a message using PossResend tag? What I think is only when there is connection drop due to network/outage or anything else and client resend the message with new sequence number. In this case client reconstruct message from persistent store.

Please correct if I am wrong or there is some better scenario.

THe example i am trying to identify is as

trade1 with sequence 100 and then it was sent again with sequence 101. But when will it happen…?

Hi Mary,

PossDup and PossResend are two flavours of the same mechanism by which
the client can re-send messages in the event the client “suspects”
data loss.

In a nut-shell…

  1. Poss Dup - Means the client is re-sending a message with the same
    sequence number of the original.

  2. Poss Resend - Means the client is re-sending a message with a newly
    stamped sequence number

Both these methods are session level re-transmission options and are not
specific to a particular message type (G in your case), and that it
applies in general to any message.

Now coming to how one should handle both…

  1. Poss Dup - As the name conveys, is a duplicate. Its being re-sent by
    the client with the same sequence number. If your receiving
    application has already got this sequence number, then “just ignore”.
    Else update your system with that message. This can be concluded at
    the session level itself since the sequence number itself is enough
    to decide whether its a duplicate for the receiver indeed.

  2. Poss Resend - Its again re-transmission but with new sequence
    numbers. Hence, here to validate whether the message is a duplicate,
    sequence number is of no use. This validation should take place in
    the application layer. Hence this requires knowledge of the message
    type. The methods are…

For New(D) / Amend(G) / Cancel(F)- Validate whether the “Client Order
ID” of the message in question is already received or not. If its a
duplicate, then discard.

For Executions (8) - Validate the “ExecID” for duplicates.

In your case… (For G) if a client sends you a message with Pos
Resend, validate the Client Order ID to see if its duplicate. If so,
just drop it.

There is no requirement to convey any information on the acceptance of
re-transmission. Its either take or discard.

Hope this helped you!

Best Regards, Thaya.

Can someone please tell me what is the expected behavior from the
broker when the broker receives (from the client) an Order
Cancel/Replace Request (MsgType G) or an Order Cancel Request (MsgType
F) with Tag 97 PossResend = `Y’ where the message is determined by the
broker to be a duplicate. Should the broker send back a message to the
client and if so what message? Or should the broker just ignore the
order request and not send anything back to the client?

Can someone also please tell me what response is required from the
broker when Tag 43 PossDup is set to `Y’ (and Tag 97 PossResend has
not been provided) in a New Order Single, Replace Request and Cancel
Request where the broker again has determined that the message is a
duplicate?