Re: Issue 174: When is an IceGatherer allowed to prune host, reflexive and relay candidates?

+1. I’m for (b) with BA’s actor suggestion and agree w/ Roman’s reasoning..

-Robin

On February 6, 2015 at 7:07:31 PM, Roman Shpount (rshpount@turbobridge.com) wrote:

On Fri, Feb 6, 2015 at 6:47 PM, Bernard Aboba <Bernard.Aboba@microsoft.com> wrote:
Robin Raymond said:

"Possible solutions:
(a) IceGatherer is told to "gather()" with a prune timeout, and candidates remain warm until the timeout has completed (and can be optionally extended by gather() again with another future timeout before the last timeout completes)
(b) IceGatherer keeps all host, reflexive and relay candidates "hot" until a "IceGatherer.prune()" method is called where it's now allowed to prune out any non-warm candidates (i.e. candidates that have not sent or received checks / data within a standard ICE consent timeout).
(c) IceGatherer keeps all host, reflexive and relay candidates "hot" so long as a single incomplete IceTransport is attached to the IceGatherer, i.e. keeping the IceGatherer warm could be done by keeping an unused IceTransport around until it's disposed."

[BA] Another option worth considering would be to add an (optional) prune timeout to the IceGatherer constructor.  That way, it would not be necessary to call gather() to begin the gathering process; gathering would start upon construction as it does now.   I realize that there is another potential use of .gather() which is to enable ICE gathering to occur again without changing the password/ufrag.  But that seems like an issue distinct from this one.


We would still need gather() to extent the timeout.

After some consideration I do like the having an optional parameter in the IceGatherer constructor for prune timeout in combination with gather() method to extend the candidate availability. The benefit of this option is that it will give the desired behavior for the most common use cases without any extra client code while allowing to implement more complex forking scenarios.

I dislike (b) since the programmer can forget to call prune which will keep all the candidates for the duration of the call without giving any indication that anything is done wrong.

Option (c) is undesirable since it requires to keep an IceTransport for no other reason except to keep the candidate hot.
_____________
Roman Shpount