moparisthebest/xeps
1
0
Fork 0
mirror of https://github.com/moparisthebest/xeps synced 2024-11-21 16:55:07 -05:00
Code Issues Releases Wiki Activity

XEP-0198: Clarify the note about counters

Browse Source 
Many implementations have failed to get this right on their first
attempt, and so this text aims to clarify the logic required for
an implementation to correctly maintain its counters for a stream.

The text was 95% based on text originally proposed by Florian Schmaus,
but I find it a bit clearer and fixed some grammar in the process.
This commit is contained in:
Matthew Wild 2018-06-29 13:47:55 +01:00 committed by Florian Schmaus
parent 41ec50a11c
commit a414185274
1 changed files with 3 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
xep-0198.xml
View File

@ -30,8 +30,8 @@
&mwild;
<revision>
<version>1.5.3</version>
<date>2017-06-27</date>
<initials>fs</initials>
<date>2017-06-29</date>
<initials>fs/mw</initials>
<remark><p>Improve the note about stream management counters in section 4.</p></remark>
</revision>
<revision>
@ -281,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 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 class='box'>Note: Each entity maintains two counters for any given stream: a counter of stanzas it has sent, and a counter of stanzas it has received and handled ('h'). The counter for an entity's own sent 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 -->