Re: [Quickfix-developers] non logged-on messages

[Caleb E. <cal...@gm...>]

On 8/31/05, Brian Erst <azz...@ya...> wrote:

I would distinguish between messages that may have been forwarded to
> your communications object and those that have simply been enqueued.
>=20
> I misspoke when I mentioned sequence-resend requests - obviously those
> require PosDup. I was envisioning the scenario when messages are being
> queued while there is no active login or socket - once the login
> occurs, the enqueued messages are sent. Would QF set the PosDup flag in
> this case?


I believe QF will set the PossDup flag on any message that is sent (or=20
re-sent) after having been read back from the MessageStore. This means any=
=20
message an application "sends" while a connection is down will be sent as a=
=20
PossDup, even if it could never have been sent before. For example, suppose=
=20
we have:

   - Session is up and running, sequence numbers are 100:100=20
   (yours:theirs)
    - Session is dropped=20
   - Your application "sends" 100 more messages, making the sequence=20
   numbers 200:100=20
   - Session reconnects, login is sent as message 201=20
   - Counterparty requests resend of messages 101-0=20
   - QF resends messages 101-200 all with PossDupFlag=3DY
   =20
QuickFIX doesn't keep track of the fact that the transport associated with =
a=20
session is up or down at the time a message is sent, so it doesn't have any=
=20
way to know if a message might have been sent before. Basically, if it has=
=20
to read a message from the MessageStore (which it will only do when=20
processing a ResendRequest), it will send it as a PossDup.

Another scenario is the case of messages that are queued due to the
> engine processing a previous sequence-resend request. For instance,
> counterparty requests messages 1-0 (all messages). At the time of the
> request, the next sequence number is 996, so messages 1-995 are
> "resends" and anything after that are not. While QF is sending messages
> 1-995, messages 996-1000 are enqueued awaiting transmission (there are
> 995 messages in front of them and the socket takes time). Would
> messages 996-1000 have PosDup? I presume not, otherwise you might never
> be able to get out of the PosDup trap.


Given a resend request from N to 0, the Session::nextResendRequest code wil=
l=20
resend all messages from N to the next-expected-sender-sequence-number - 1=
=20
with PossDupFlag=3DY. In this case it would be 1-995. This is done while=20
holding the Session's mutex locked, so it will not be possible to send any=
=20
additional messages. Your application code would be blocked waiting on that=
=20
mutex. I think this is more or less what you'd expect.

I believe the answer to both questions above should be "no" and assume that=
=20
> QF works that way as well.


You know the old saying about "assume" :-)

Seriously though. You raise some interesting points about keeping closer=20
track of which messages could/could not have possibly been sent previously.=
=20
This is something that the SessionState could perhaps keep track of, but it=
=20
would complicate the code for questionable benefit.

What is the harm in sending a message that might never before have been sen=
t=20
as a PossDup? I know in our trading systems we don't even really make use o=
f=20
this flag at all. We do dupe detection based on IDs like ClOrdID, ExecID an=
d=20
the like and this has stood us in good stead.

--=20
Caleb Epstein
caleb dot epstein at gmail dot com