One thing to remember, I think, is that individually the cases are going to be incredibly rare, but in the case of widespread adoption, these once-in-a-lifetime cases will pop up for *someone* out there on a frequent basis. While I agree that the worst thing that can happen is a 10-second pause, I don't see a compelling need to allow them to happen - and they will, even though most users will never see them - when preventing them is so simple. The purpose of RTT, in the first place, is not to have these kinds of delays.
I do two things to prevent this from happening: - on the receiver side I do modulo 2**31 arithmetic - on the sender side I limit the maximum random sequence restart number to 2**30. Christian On Thu, Apr 11, 2013 at 7:14 PM, Mark Rejhon <[email protected]> wrote: > 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 > -- Christian Vogler, PhD Director, Technology Access Program Department of Communication Studies SLCC 1116 Gallaudet University http://tap.gallaudet.edu/ VP: 202-250-2795
