[Nice] Bug: Gather candidates never completes

[Youness Alaoui]

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
>>>>> http://lists.freedesktop.org/mailman/listinfo/nice
>>
>>
>>


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 262 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freedesktop.org/archives/nice/attachments/20100824/8e4d92f2/attachment.pgp>