[Standards] XEP-0301 0.5 comments [resetting versus randomizing 'seq' attribute]

Mark Rejhon markybox at gmail.com
Fri Jul 27 21:21:17 UTC 2012


On Fri, Jul 27, 2012 at 4:41 PM, Gunnar Hellström
<gunnar.hellstrom at omnitor.se> wrote:
> But do you need unique seq start number? Then it is not sufficient to take a
> random number. Then you really need to use an algoritm that makes sure it is
> unique.

It is impossible.
You cannot guarantee uniqueness via 'seq' between two senders (at
least on a 47 year time scale :-) unless you are using Full JID or
<thread/>.   Different uniqueness algorithms are available, but random
is pretty sufficient.  I only need something that is "sufficiently
unique" for a SHORT timescale (e.g. the interval between two <rtt/>
elements) --

EXAMPLE: Minimize the odds of consecutive increments from separate resources.
Concurrent Login #1 sends <rtt seq='3'/> followed by
Concurrent Login #2 sends <rtt seq='4'/>, causing a "false valid"
<rtt/> to corrupt real-time text.
(MUC may not have bare JID, so can't distinguish Login #1 and Login #2)
(Note: Corruption fixes itself during the next Message Reset)

This scenario is far more likely to happen when using defined value at
a defined time (e.g. setting to 0 at startup, setting to 0 every 'new'
/ 'reset').  One user logs on, the other user logs on.  One login #1
types, then the other login #2 types, sends a few messages and lets
the seq re-increment back to close to the value that the unattended
login #1 has.  Then login #1 resumes typing, sending false-valid
<rtt/>.

Random is significantly more secure than setting an exact value at any
time in program operation (startup or new message).  If you're very
concerned about "coincidence" situations, just use use full JID and
<thread/> to prevent collisions between implementations -- I even
recommend this.  But we're not going to REQUIRE it.

There are other algorithms, but they dramatically increase complexity,
and please note that at least one XSF member has already questioned
the concept of putting lower-level network layer stuff into a
higher-layer.  I am keeping it minimum to the needs found in section
"Keeping Real-Time Text Synchronized"

Again, YOUR implementation can guarantee uniqueness using <thread/> or
full JID. (Note: full JID may not be available in all MUC's)

Thanks,
Mark Rejhon



More information about the Standards mailing list