XEP-0198: Clarify the note about counters

The note was only 50% correct (the counter the note talks get
initialized and started when the entity receives <enable(d)/>, and not
when it is sent) and partly misleading (there are typically four
counters per stream). Most XEP-0198 Stream Management implementations
I am aware of didn't get the counters right at the first time. The
tricky part is to get the time right where the counters should be set
to zero and get started. The new note's text tries to help
implementers with this. As bonus, it is also shorter than the original
note.
This commit is contained in:
Florian Schmaus 2018-06-27 20:28:12 +02:00
parent d01853d08f
commit 41ec50a11c
1 changed files with 7 additions and 1 deletions

View File

@ -28,6 +28,12 @@
&fabio;
&dcridland;
&mwild;
<revision>
<version>1.5.3</version>
<date>2017-06-27</date>
<initials>fs</initials>
<remark><p>Improve the note about stream management counters in section 4.</p></remark>
</revision>
<revision>
<version>1.5.2</version>
<date>2016-12-08</date>
@ -275,7 +281,7 @@
<p class='def'><strong>Definition:</strong> Acknowledging a previously-received ack element indicates that the stanza(s) sent since then have been "handled" by the server. By "handled" we mean that the server has accepted responsibility for a stanza or stanzas (e.g., to process the stanza(s) directly, deliver the stanza(s) to a local entity such as another connected client on the same server, or route the stanza(s) to a remote entity at a different server); until a stanza has been affirmed as handled by the server, that stanza is the responsibility of the sender (e.g., to resend it or generate an error if it is never affirmed as handled by the server).</p>
<p>Receipt of an &lt;r/&gt; element does not imply that new stanzas have been transmitted by the peer; receipt of an &lt;a/&gt; element only indicates that new stanzas have been processed if the 'h' attribute has been incremented.</p>
<p>The value of 'h' starts at zero at the point stream management is enabled or requested to be enabled (see note below). The value of 'h' is then incremented to one for the first stanza handled and incremented by one again with each subsequent stanza handled. In the unlikely case that the number of stanzas handled during a stream management session exceeds the number of digits that can be represented by the unsignedInt datatype as specified in &w3xmlschema2; (i.e., 2<span class='super'>32</span>), the value of 'h' SHALL be reset from 2<span class='super'>32</span>-1 back to zero (rather than being incremented to 2<span class='super'>32</span>).</p>
<p class='box'>Note: There are two values of 'h' for any given stream: one maintained by the client to keep track of stanzas it has handled from the server, and one maintained by the server to keep track of stanzas it has handled from the client. The client initializes its value to zero when it sends &lt;enable/&gt; to the server, and the server initializes its value to zero when it sends &lt;enabled/&gt; to the client (it is expected that the server will respond immediately to &lt;enable/&gt; and set its counter to zero at that time). After this initialization, the client increments its value of 'h' for each stanza it handles from server, and the server increments its value of 'h' for each stanza it handles from the client.</p>
<p class='box'>Note: There are four stream management counters for any given stream: Every side of the stream maintains a counter of its own send stanzas and a counter of the received and handled stanzas ('h'). The counter for an entities own send stanzas is set to zero and started after sending either &lt;enable/&gt; or &lt;enabled/&gt;. The counter for the received stanzas ('h') is set to zero and started after receiving either &lt;enable/&gt; or &lt;enabled/&gt;.</p>
<p>The following annotated example shows a message sent by the client, a request for acknowledgement, and an ack of the stanza.</p>
<example caption='Simple stanza acking'><![CDATA[
<!-- Client -->