<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
<font face="Calibri">It does, thank you - and it points to the need for
me to re-read the spec again!<br>
<br>
:)<br>
</font><br>
On 5/10/2010 10:30 AM, Robert Godfrey wrote:
<blockquote
cite="mid:AANLkTinHOMhu2K7FByYxaxmNSB896SmJWydyj8kqywHt@mail.gmail.com"
type="cite">
<pre wrap="">Hi Colin,
On 10 May 2010 16:32, Colin Clark <a class="moz-txt-link-rfc2396E" href="mailto:colin@cloudeventprocessing.com"><colin@cloudeventprocessing.com></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">
We use sequence numbers for flow control, this is separate from the
tag used for de-duplication.
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">
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
</pre>
</blockquote>
</body>
</html>