1. 21 Jun, 2018 2 commits
  2. 19 Jun, 2018 2 commits
  3. 18 Jun, 2018 3 commits
  4. 12 Jun, 2018 1 commit
  5. 06 Jun, 2018 4 commits
  6. 04 May, 2018 3 commits
  7. 23 Mar, 2018 11 commits
  8. 22 Mar, 2018 1 commit
  9. 28 Nov, 2017 4 commits
  10. 27 Nov, 2017 2 commits
  11. 12 Sep, 2017 3 commits
  12. 05 Sep, 2017 4 commits
    • Fabrice Bellet's avatar
      conncheck: change state before updating nominated pairs · 14102d44
      Fabrice Bellet authored
      When a pair is nominated while in state failed, we first move
      back to state connecting, then we update the selected pair, and
      finally we move to state connected.
      14102d44
    • Fabrice Bellet's avatar
      conncheck: forgot to put a pair in triggered check list · 72dd26a3
      Fabrice Bellet authored
      When a new pair is created from an unknown remote candidate, it
      should be enqueue for a triggered check, to allow it to be marked
      as nominated on response arrival in priv_mark_pair_nominated().
      Creating it in waiting state is not sufficient since the update
      in priv_mark_pair_nominated() from previous commits.
      
      Differential Revision: https://phabricator.freedesktop.org/D1763
      72dd26a3
    • Fabrice Bellet's avatar
      conncheck: update the state of triggered checks pairs · 6fe64fdb
      Fabrice Bellet authored
      With this patch, we fix an ambiguity of some parts of the spec, when
      the document refers to in-progress pairs, that also concern pairs in
      the triggered checks list.
      
      The first cast is in section 7.1.2.5, "Updating the Nominated Flag",
      when the in-progress pair will be nominated on response arrival. This is
      handled in function priv_mark_pair_nominated(), when a pair is put to
      the triggered check list in reaction to a matching inbound stun request.
      Such a pair in priv_mark_pair_nominated() will _always_ be in the
      triggered check list, from the previously called function
      priv_schedule_triggered_check().
      
      The second case is in section 8.1.2, "Updating State" when an in-progress
      pair stops its retransmission when another pair of higher priority is
      already nominated. This is handled by function priv_prune_pending_checks().
      
      Until now, pairs enqueued in the triggered check list move transiently
      to state waiting, according to 7.2.1.4. But this state causes wrong
      decisions in the two previous cases, because such pairs should in fact
      rather be considered "like in-progress", to avoid discarding them
      inadvertantly.
      
      This patch update the state of the triggered check list
      pairs to in-progress. It allows to remove exception handling cited
      above: the code is a bit more simple, and allows some refactoring
      in priv_mark_pair_nominated() between RFC and compatibility modes.
      
      Differential Revision: https://phabricator.freedesktop.org/D1762
      6fe64fdb
    • Fabrice Bellet's avatar
      conncheck: support several stun requests per pair · 36f306f4
      Fabrice Bellet authored
      This patch should improve the reliabily of the connection check by
      keeping the record of several simultaneous ongoing stun requests per
      pair. A new stun request on an in-progress pair typically is caused by
      in inbound stun request from the peer on this same pair. This is named
      "Triggered Checks" in the spec. When this situation arises, it is fair
      to handle these two stun requests simultaneously, the triggered check,
      and the initial ordinary check, since both can potentially succeed.
      
      Differential Revision: https://phabricator.freedesktop.org/D1761
      36f306f4