Re: Issue 164: IceGatherer States

Clear. Thanks a lot.

2015-01-05 19:51 GMT+01:00 Bernard Aboba <Bernard.Aboba@microsoft.com>:
> Inaki said:
>
> "Maybe I miss something, but I see zero value for the new sleeping state. Why is it useful to know when the non-nominated candidate pairs have been pruned?"
>
> [BA] To my mind pruning/nomination is something that is relevant only to IceTransport objects and not to IceGatherer objects, so if you want to know when non-nominated candidate pairs have been pruned, the IceGatherer is not the right object to consult.
>
> As to why we might care, the question has arisen as to what candidates exist within an IceGatherer at various times.   For example, once the IceTransport has completed connectivity checks, are the non-nominated candidates pairs removed from the IceGatherer?   Or is the IceGatherer unaffected by the nomination/pruning process within the IceTransport?   If the IceGatherer is unaffected by nomination/pruning, then I believe we do not need to care and the "sleeping" state can be deleted.
>
> If we do need to care, I think we have got a problem because having the IceGatherer affected by nomination/pruning within the IceTransport has some nasty side effects.
>
> Let us consider a forking scenario, where a single IceGatherer is provided as an argument to IceTransport.start() for multiple IceTransport objects.   If the nomination/pruning on one IceTransport were to affect the candidates available within the IceGatherer,   then using a single IceGatherer as an argument to IceTransport.start() for each fork could have unpredictable behavior.  For example, if one fork completes ICE connectivity checks and prunes candidate pair(s), does this mean that when another fork calls IceTransport.start(iceGatherer) that only nominated candidates are available??  To avoid these side effects, it would be safer to construct a distinct IceGatherer object for each fork, but the whole point of the IceGatherer was to allow for reuse.
>
>



-- 
Iñaki Baz Castillo
<ibc@aliax.net>

Received on Friday, 9 January 2015 19:30:25 UTC