[rabbitmq-discuss] request for help!

Mon May 10 16:30:59 BST 2010

Hi Colin,

On 10 May 2010 16:32, Colin Clark <colin at cloudeventprocessing.com> wrote:
> In regards to the once-and-only-once discussion below:
>
> In many financial formats, like FIX and others, we utilize message ID's that
> help with this behavior a lot.  It also prevents from messages being
> delivered out of sequence.  For example.
>
> Client logs in - server and client at message ID of 0,
> every message that the server sends has an incremented ID,
> if the client receives an unexpected ID, it can either request a retransmit
> from the last known or kill the session,
> when a client logs back in, the client logs in with the expected ID, server
> & client negotiate and session resumes.
> (there are id's for both the client & server messages, both incremented for
> each message and the above behavior applies on both sides of the connection)
>
> FIX employs an optimistic delivery protocol, i.e., assume that it was
> received.  There is no session level ack.  Only an ack at the application
> level; and that ack is not mandatory.  Use of the message ID provides the
> once & only once and in order semantics required for trading; a behavior
> that is obviously very useful elsewhere as well.
>
> Using sequence #'s also allows for advanced concepts such as flow control -
> I haven't read enough of the spec yet to see if that's a feature yet or not.

We use sequence numbers for flow control, this is separate from the
tag used for de-duplication.

> I do agree, if a message is sent, then an ack is waited for, sending an ack
> of ack seems a little over kill to me.  Perhaps it's time for me to read the
> whole spec again.
>

As I (and Rafi who seems to have simultaneously said much the same
thing :-) ) have said, this is not required behaviour.  You can
*choose* to behave in this way, but for the use case above I very much
doubt that is how you would want to behave.  The receiver can
periodically notify the sender as to the high-watermark of messages
that it considers settled - this will give the same behaviour as
above.

Hope this helps,
Rob