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

[Brian E. <azz...@ya...>]

Caleb -

I would distinguish between messages that may have been forwarded to
your communications object and those that have simply been enqueued.

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?

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.

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

- Brian

--- Caleb Epstein <cal...@gm...> wrote:

> On 8/31/05, Brian Erst <azz...@ya...> wrote:
> 
> 
> I would expect that perhaps the first message that gets enqueued due
> to
> > a missing socket connection might have to be PosDup'd (perhaps the
> > socket connection disappeared during a send), but on subsequent
> > messages the engine would know for sure whether that message had
> ever
> > been sent to the counterparty (even though it may not know whether
> it
> > reached the counterparty). Almost by definition, any message with a
> > sequence number greater than the sequence number of last message
> that
> > actually reached a valid socket/network-stream object is NOT a
> PosDup.
> > 
> 
> But you can't know which of your sequence numbers your counterparty
> is up 
> to! Well, you could reconnect, or initiate a Test request and wait
> for the 
> response. But sockets have buffers and networks go down and
> applications 
> crash, so a successful send() on your end doesn't always mean the
> other side 
> will recv() it. So you may have think you have sent several messages
> that 
> your counterparty never got.
> 
> In our own home-rolled FIX engine we don't set the PosDup flag unless
> > the message is sent due to a sequence-resend request and the
> sequence
> > number is below the sequence number of the last known attempt at
> > transmission.
> 
> 
> But what if your last-known-attempt counter is too high (as I think I
> 
> describe above)? I think this behavior is in violation of the spec,
> which 
> says that the PossDupFlag will be set to Y on any message sent in
> response 
> to a resend request. If a counterparty asks you for a bunch of
> messages, you 
> shouldn't presume to know better than they do which ones they haven't
> seen 
> yet :-)
> 
> -- 
> Caleb Epstein
> caleb dot epstein at gmail dot com
>