This CL adds the flag "PORTALLOCATOR_ENABLE_ANY_ADDRESS_PORTS", which will
force the creation of ports not bound to any specific network interface.
These are normally only used when network enumeration fails or is disabled,
but in some circumstances (such as the one the test case adds), they're the
only thing that works.
This will result in extra ports being gathered, which is why it's only enabled
behind a flag for now. In the future, we could probably introduce more
sophisticated "pruning" logic that would lessen the impact of the extra ports
when they're redundant, and make the flag the default.
Some other minor changes that were required to make this use case work:
* Allow a TCPPort to be used for outgoing connections even if it tries and
fails to create a server socket.
* Allow Bind to fail if being called before Connect, and the IP is an "any"
address (0.0.0.0 or ::), since this bind would have been mostly pointless
anyway.
* Prevent P2PTransprotChannel from keeping a "backup" candidate pair using
an "any address" network; we only want this for actual networks.
BUG=webrtc:7798
Review-Url: https://codereview.webrtc.org/2936553003
Cr-Commit-Position: refs/heads/master@{#18578}
When the selected connection becomes not receiving and there are many connections,
If we use a round-robin fashion to ping all connections, none of the connections will
be in receiving state for sufficient long time to ensure switching connections promptly.
Triggered check will help in this situation to some extent but it may still fail to switch promptly when there are a lot of connections.
With this CL, if the selected connection is weak, once we find a writable connection on a network we start to ping it with a higher priority to keep it in receiving state.
Plus, if the selected connection is weak, we choose a shorter ping interval (900ms) for all writable connections.
BUG=b/32022719
Review-Url: https://codereview.webrtc.org/2369963004
Cr-Commit-Position: refs/heads/master@{#14991}
This helps a lot on Android devices where the user threads can be scheduled with low priority when the app is in the background, causing spurious significantly delayed before a packet can be read from the socket. With this patch the timestamp is taken by the kernel when the packet actually arrives.
R=juberti@chromium.orgTBR=juberti@webrtc.org
BUG=webrtc:5773
Review URL: https://codereview.webrtc.org/1944683002 .
Cr-Commit-Position: refs/heads/master@{#12850}
Mostly this consists of marking functions with override when
applicable, and moving function bodies from .h to .cc files.
Not inlining virtual functions with simple bodies such as
{ return false; }
strikes me as probably losing more in readability than we gain in
binary size and compilation time, but I guess it's just like any other
case where enabling a generally good warning forces us to write
slightly worse code in a couple of places.
BUG=163
R=kjellander@webrtc.org, tommi@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/47429004
Cr-Commit-Position: refs/heads/master@{#8656}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8656 4adac7df-926f-26a2-2b94-8c16560cd09d
