RFC5242, section 5.2 (determining role) describes the tie-breaker value as
follows:
To resolve this, each agent MUST select a random number, called
the tie-breaker, uniformly distributed between 0 and (2**64) - 1
(that is, a 64-bit positive integer). This number is used in
connectivity checks to detect and repair this case, as described
in Section 7.1.2.2.
The tie-breaker is a 64 bit unsigned number. Right now, ice4j uses the signed
'long' type to store this value. Unfortunately, blind comparisons of
tie-breaker values cast as 'long' will fail in cases where a large tie breaker
value with the top bit set to '1' will be interpreted as negative and less than
a lower value.
For an example, try comparing 0xffff_ffff_ffff_ffff (or -1) to 0 using longs.
For this case, 0xffff_ffff_ffff_ffff should win since it's the greater unsigned
value, but since it will be cast as '-1', it will lose the comparison.
Since java doesn't support unsigned long types, I added a helper function to
compare two long values as if they were unsigned long values and will correct
this bug.
The patch also adds another helper function to set the tieBreaker value in case
a user of the library needs to override the generated tieBreaker value to force
ice4j to assume the ICE-CONTROLLING role.
Original issue reported on code.google.com by m...@fredricknet.net on 14 Apr 2015 at 7:29
Original issue reported on code.google.com by
m...@fredricknet.neton 14 Apr 2015 at 7:29Attachments: