On 2013-04-12 01:41, Christian Vogler wrote:
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.
I hope you mean:
- on the sender and receiver side I do modulo 2**31 arithmetic
- on the sender side I limit the maximum random sequence restart number
to 2**30.
That seems to be a good conclusion from version 0.7 that you had at hand
when you made your implementation.
---------------------------------------------------------------
I cannot find that we discussed and concluded in the list to delete the
precaution for effects of wrap-around. Therefore I expected it to be
included in v.0.8, and suggest that it is put in again.
/Gunnar
Christian
On Thu, Apr 11, 2013 at 7:14 PM, Mark Rejhon <[email protected]
<mailto:[email protected]>> wrote:
Regarding:
http://xmpp.org/extensions/xep-0301.html
On Thu, Apr 11, 2013 at 4:45 PM, Gunnar Hellstrom
<[email protected] <mailto:[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."
It should be specified where seq itself is specified.
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.
It was agreed in July and not discussed after that so it should stay in.
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
/Gunnar
