Remove candidates when doing continual gathering

webrtc/p2p/base/candidate.h

 /*
  *  Copyright 2004 The WebRTC Project Authors. All rights reserved.
  *
  *  Use of this source code is governed by a BSD-style license
  *  that can be found in the LICENSE file in the root of the source
  *  tree. An additional intellectual property rights grant can be found
  *  in the file PATENTS.  All contributing project authors may
  *  be found in the AUTHORS file in the root of the source tree.
  */
 
@@ skipping 152 matching lines @@
     // We ignore the network name, since that is just debug information, and
     // the priority, since that should be the same if the rest is (and it's
     // a float so equality checking is always worrisome).
     return (component_ == c.component_) && (protocol_ == c.protocol_) &&
            (address_ == c.address_) && (username_ == c.username_) &&
            (password_ == c.password_) && (type_ == c.type_) &&
            (generation_ == c.generation_) && (foundation_ == c.foundation_) &&
            (related_address_ == c.related_address_);
   }
 
+  // Determines whether this candidate can be considered equivalent to the
+  // given one when looking for a matching candidate to remove.
+  bool MatchesForRemoval(const Candidate& c) const {
+    return component_ == c.component_ && protocol_ == c.protocol_ &&
+           address_ == c.address_;
+  }
+

[Taylor Brandstetter, 2016/02/10 21:58:08]

Why can't IsEquivalent be used?

[pthatcher1, 2016/02/11 20:25:51]

Because then we have to signal everything.  It would be nice to just have to
signal what's needed (the 3 tuple).

[Taylor Brandstetter, 2016/02/11 20:55:17]

Is there a reason why signaling the whole candidate is difficult?

[honghaiz3, 2016/02/12 00:56:55]

Signaling everything will consume unnecessary bandwidth. 
In theory, another option is to fill up the missing information like here:
https://code.google.com/p/chromium/codesearch#chromium/src/third_party/webrtc...
and then apply IsEquivalent. 
but I think adding a new method would require less computation. 
Do you think there is any case that protocco, address and component is the same
but other fields may be different so that we should treat the two candidates
differently?

   std::string ToString() const {
     return ToStringInternal(false);
   }
 
   std::string ToSensitiveString() const {
     return ToStringInternal(true);
   }
 
   uint32_t GetPriority(uint32_t type_preference,
                        int network_adapter_preference,
@@ skipping 60 matching lines @@
   virtual ~CandidateTranslator() {}
   virtual bool GetChannelNameFromComponent(
       int component, std::string* channel_name) const = 0;
   virtual bool GetComponentFromChannelName(
       const std::string& channel_name, int* component) const = 0;
 };
 
 }  // namespace cricket
 
 #endif  // WEBRTC_P2P_BASE_CANDIDATE_H_