[Nice] Bug: Gather candidates never completes

[Tom Kaminski]

> 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 ?

I think your solution would be very good for the default timeouts.
However, they should still be configurable.  I think that if the
timeouts are going to be added to the API perhaps it should be
specified using an INITIAL_TIMEOUT, and MAX_TRANSMISSIONS variables,
rather than an END_TIMEOUT.  The reason being is that you can nicely
express the final timeout value as:

TIMED_OUT = INITIAL_TIMEOUT*(2^MAX_TRANSMISSIONS-1)

And this equation can be documented in the API.  You can't form such
an expression with END_TIMEOUT.  Secondly, from the perspective of the
user of the API, it is very clear what MAX_TRANSMISSIONS would mean.

Tom


>>>> _______________________________________________
>>>>>> Nice mailing list
>>>>>> Nice at lists.freedesktop.org
>>>>>> http://lists.freedesktop.org/mailman/listinfo/nice
>>>
>>>
>>>
>
>
>