[Nice] Bug: Gather candidates never completes
youness.alaoui at collabora.co.uk
Tue Aug 24 18:55:12 PDT 2010
On 08/24/2010 09:40 PM, Tom Kaminski wrote:
>>> adjust the timeout for the discovery part. I've updated the values
>>> so that it times out after 2.3 seconds which is tolerable.
>> Yes, for connectivity checks, we don't really care, 9 seconds for 'connecting'
>> is quite fine.. but for stun it's too much..
>> How did you come up with the 2.3 seconds ? what is the upper limit and what is
>> the initial delay interval you set ? and why those values? Did you do some
>> testing to see if it's more efficient in real life or did you just take it
>> randomly ?
> Here is what I am using now:
> #define STUN_INIT_TIMEOUT 300 //600
> #define STUN_END_TIMEOUT 1000 //4800
> I tried using smaller timeout values (ie. STUN_END_TIMEOUT=500), but
> then the connection establishment started to fail. So I bumped it up
> to 1000 ms. The round trip time between my computer (winnipeg) and
> peers in central europe is around 250 ms so four times that value
> should be fairly safe. The total timeout = STUN_INIT_TIMEOUT +
> 2*STUN_END_TIMEOUT = 2.3 seconds. Not quite random, but I didn't do
> any exhaustive testing either. What I can say is that these timeout
> values are working well for me so far.
ok, cool, the current libnice does 4 retransmissions, at 0ms, 600ms, 1800ms,
4200ms, then fails at 9000ms.
In your case it becomes : 0ms, 300ms, 900ms, then fails at 2100ms. So you get 3
transmissions. And no, the algo you used is wrong :p
The initial timeout is set, and the delay is doubled everytime, so you start with :
0ms : delay 300ms
0 + 300ms : delay 600ms
300 + 600ms : delay 1200ms >= END_TIMEOUT, no more retransmissions.
900ms + 1200ms : timed out.
Actually, I think we should set the initial delay to 200ms.. I know it's too low
for many people (250/300ms ping for some servers) but it doesn't really matter,
a retransmitted packet will not harm anyone anyways and I'll try to have a goal
of 3seconds total timeout :
0ms : delay 200ms
200ms : delay 400ms
600ms : delay 800ms
1400ms : delay 1600ms >= END_TIMEOUT , no more retransmissions
3000ms : timed out
It's perfect! This way, I think 3seconds is quite acceptable too.. and we still
keep our '4 retransmissions' as we did before. So my solution would be :
#define STUN_INIT_TIMEOUT 200
#define STUN_END_TIMEOUT 1600
What do you think ?
>>>>> Nice mailing list
>>>>> Nice at lists.freedesktop.org
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 262 bytes
Desc: OpenPGP digital signature
More information about the Nice