Regarding: http://xmpp.org/extensions/xep-0301.html
On Thu, Apr 11, 2013 at 4:45 PM, Gunnar Hellstrom <[email protected]> wrote: > On 2013-04-11 00:09, Gunnar Hellstrom wrote: >> I remember that there was a discussion on the risk for wrap-over in >> handling seq. Is the wording now in line with the outcome of the discussion? >> Was it acceptable as it is now, with no mentioning about the risk for >> wrap-around when incrementing seq. Maybe all implementors should be wise >> enough to handle wrap around properly. Or did the discussion end up with the >> conclusion that a requirement should be inserted about usual handling of the >> counter wrapping around? Wraparound risk is so low: (1) The damage of a seq wraparound is insignificant (2) If both ends use the same seq wrapping bounds, both ends will wraparound simultaneously and real time text continues; (3) In the worst-case scenario (seq values diverges during wraparound) section "Keeping Real Time Text Synchroized" will simply freeze the text for 10 seconds until the next Message Refresh, at which point seq gets re-initialized. http://xmpp.org/extensions/xep-0301.html#keeping_realtime_text_synchronized (4) It is unlikely that seq would be randomized very near the top bounds of seq for a specific 10 second window, to cause another wraparound. IMHO, it is almost a waste of text to expand XEP-0301 any further for something so harmless/rare as this. Presently, a seq wraparound has never ever happened in the history of XEP-0301 to the best of my knowledge, and even when programmatically forced to do so, situation (2) typically happens -- both ends wrap automatically from 2,147,483,647 directly to 0 simultaneously -- and the real-time text continues synchronized. Can anybody illustrate any use-cases why this discussion is important? > It was handled in a mail of July 27, 2012, where you said about text about > the initial value on SEQ for section 4.2.1: > > I already say "Senders MAY limit the size of the new starting seq > value, to keep <rtt/> compact while allowing plenty of incrementing > room without overflow." which already provides the umbrella for this. > > I found no further change on this, so I think the sentence in" " above > should be in section 4.2.1 I have a better idea: I should move the sentence mentioning "The bounds of seq are 31-bits, the range of positive values for a signed 32-bit integer." Wraparounds are completely harmless if proper wraparound is done, and simply results in situation (2) if followed. The additional talk is simply "just in case" stuff in case the wraparound logic on both ends is different, and even when the wraparound logic is different/buggy/poorly done, the side effects are quite harmless, like a "once-in-a-century" 10 second pause. Thanks, Mark Rejhon
