[rabbitmq-discuss] request for help!

Mon May 10 16:37:29 BST 2010

It does, thank you - and it points to the need for me to re-read the 
spec again!

:)

On 5/10/2010 10:30 AM, Robert Godfrey wrote:
> 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
>    
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20100510/759fdec1/attachment.htm 