A controlled Agent would discard incoming Binding Requests if it didn't
cause the pair to be selected. For UDP Candidate this would be
interpreted as packet loss. For TCP Candidates not responding with a
Binding Success could be interpreted as a failure.
Firefox's ICE Agent would disconnect TCP Candidates because of this
behavior.
Resolves to pion/webrtc#2125
Resolves to pion/webrtc#1356
See https://bugzilla.mozilla.org/show_bug.cgi?id=1756460
Before then nominating a candidate pair we limited the
amount of requests we sent, and would set the connection
to failed.
This change removes that limit, and instead uses the Disconnected+Failed
timer to control this. I found this when debugging an unrelated thing,
and was surprised by the behavior. I didn't find anything in the spec
that mentioned this, and isn't a knob that users will understand how to
control easily.
Selection before was written in a way that wouldn't work for restarts.
This moves the code out and makes it stateless. In the future we will be
able to clear the candidates and update the ConnectionState and
everything will restart properly.
Relates to #190
Remove taskChan and make .run just take an Agent wide mutex and run the
function. These is now a blocking operation so all channels used to
communicate from it must be buffered.
After this we will slowly remove usage of .run and make things more
thread safe.
Relates to #80, #67, #2
Before if Controlled side never got any candidates
it would never properly shut down. We never checked
the start time against candidateSelectionTimeout
Resolvespion/webrtc#854
Allow the agent to run in Lite mode. This is useful in
cases where you never want connectivity checks, and reduces
possible attacks surfaces when you have a public IP.
Receiving the messages with transaction ID that is currently not in
progress is expected.
* Change output format to hexademical to improve readability
* Change log severity to warning
* Update wording (invalid -> unknown)
Relates to #59
This implements a basic validation schema using a checklist. We try
every pair at least maxTries, and mark it as failed if we don't get a
success response after that many requests. Once we get a success
response, we check if it belongs to the best candidate available so far,
if it does we nominate it, otherwise we continue.
Also, after a given timeout, if no candidate has been nominated, we
simply choose the best valid candidate we got so far (if no candidate is
valid, we mark the connection as failed).
Finally, the nomination request also has a maximum of maxTries, we mark
the connection as failed if after that many attempt we fail to get a
success response.
This change will allow us to have custom logic and members
per interface type. Relay candidates will have a completely different
read loop, and candidate specific state.
Relates to #47
