Relanding because the broken chromium test has been fixed:
https://chromium-review.googlesource.com/582196
This CL moves the responsibility for restricting the number of IPv6
interfaces used for ICE to BasicPortAllocator. This is the right place
to do it in the first place; it's where all the rest of the filtering
occurs. And NetworkManager shouldn't need to know about ICE limitations;
only the ICE classes should.
Part of the reason I'm doing this is that I want to add a
"max_ipv6_networks" API to RTCConfiguration, so that applications can
override the default easily (see linked bug). But that means that
PeerConnection would need to be able to call "set_max_ipv6_networks" on
the underlying object that does the filtering, and that method isn't
available on the "NetworkManager" base class. So rather than adding
another method to a place it doesn't belong, I'm moving it to the place
it does belong.
In the process, I noticed that "CompareNetworks" is inconsistent with
"SortNetworks"; the former orders interfaces alphabetically, and the
latter reverse-alphabetically. I believe this was unintentional, and
results in undesirable behavior (like "eth1" being preferred over
"eth0"), so I'm fixing it and adding a test.
BUG=webrtc:7703
Review-Url: https://codereview.webrtc.org/2983213002
Cr-Original-Commit-Position: refs/heads/master@{#19112}
Committed: ad9561404c
Review-Url: https://codereview.webrtc.org/2983213002
Cr-Commit-Position: refs/heads/master@{#19159}
Reason for revert:
Breaks IpcNetworkManagerTest.TestMergeNetworkList, because it has built-in assumptions about network ordering that it shouldn't have. Will reland after fixing that test.
Original issue's description:
> Move "max IPv6 networks" logic to BasicPortAllocator, and fix sorting.
>
> This CL moves the responsibility for restricting the number of IPv6
> interfaces used for ICE to BasicPortAllocator. This is the right place
> to do it in the first place; it's where all the rest of the filtering
> occurs. And NetworkManager shouldn't need to know about ICE limitations;
> only the ICE classes should.
>
> Part of the reason I'm doing this is that I want to add a
> "max_ipv6_networks" API to RTCConfiguration, so that applications can
> override the default easily (see linked bug). But that means that
> PeerConnection would need to be able to call "set_max_ipv6_networks" on
> the underlying object that does the filtering, and that method isn't
> available on the "NetworkManager" base class. So rather than adding
> another method to a place it doesn't belong, I'm moving it to the place
> it does belong.
>
> In the process, I noticed that "CompareNetworks" is inconsistent with
> "SortNetworks"; the former orders interfaces alphabetically, and the
> latter reverse-alphabetically. I believe this was unintentional, and
> results in undesirable behavior (like "eth1" being preferred over
> "eth0"), so I'm fixing it and adding a test.
>
> BUG=webrtc:7703
>
> Review-Url: https://codereview.webrtc.org/2983213002
> Cr-Commit-Position: refs/heads/master@{#19112}
> Committed: ad9561404cTBR=zhihuang@webrtc.org,pthatcher@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=webrtc:7703
Review-Url: https://codereview.webrtc.org/2984853002
Cr-Commit-Position: refs/heads/master@{#19114}
This CL moves the responsibility for restricting the number of IPv6
interfaces used for ICE to BasicPortAllocator. This is the right place
to do it in the first place; it's where all the rest of the filtering
occurs. And NetworkManager shouldn't need to know about ICE limitations;
only the ICE classes should.
Part of the reason I'm doing this is that I want to add a
"max_ipv6_networks" API to RTCConfiguration, so that applications can
override the default easily (see linked bug). But that means that
PeerConnection would need to be able to call "set_max_ipv6_networks" on
the underlying object that does the filtering, and that method isn't
available on the "NetworkManager" base class. So rather than adding
another method to a place it doesn't belong, I'm moving it to the place
it does belong.
In the process, I noticed that "CompareNetworks" is inconsistent with
"SortNetworks"; the former orders interfaces alphabetically, and the
latter reverse-alphabetically. I believe this was unintentional, and
results in undesirable behavior (like "eth1" being preferred over
"eth0"), so I'm fixing it and adding a test.
BUG=webrtc:7703
Review-Url: https://codereview.webrtc.org/2983213002
Cr-Commit-Position: refs/heads/master@{#19112}
It takes a bool argument, but unconditionally sets the flag to "true".
Since no comment is left to offer an explanation, I'm assuming this was
an accident.
BUG=webrtc:7716
TBR=pthatcher@webrtc.org
Review-Url: https://codereview.webrtc.org/2974873002
Cr-Commit-Position: refs/heads/master@{#18959}
I used a command like this to update the paths:
perl -pi -e "s/webrtc\/base/webrtc\/rtc_base/g" `find webrtc/rtc_base -name "*.cc" -o -name "*.h"`
Changes since last attempt: Some system headers were moved back to their original location since on Windows compilation breaks otherwise.
BUG=webrtc:7634
NOTRY=True
NOPRESUBMIT=True
TBR=kwiberg@webrtc.org
Review-Url: https://codereview.webrtc.org/2966523003
Cr-Commit-Position: refs/heads/master@{#18868}
I used a command like this to update the paths:
perl -pi -e "s/webrtc\/base/webrtc\/rtc_base/g" `find webrtc/rtc_base -name "*.cc" -o -name "*.h"`
BUG=webrtc:7634
NOTRY=True
NOPRESUBMIT=True
TBR=kwiberg@webrtc.org
Review-Url: https://codereview.webrtc.org/2963273002
Cr-Commit-Position: refs/heads/master@{#18856}
Reland the base->rtc_base without adding stub headers (will be
done in follow-up CL). This preserves git blame history of all files.
BUG=webrtc:7634
NOTRY=True
TBR=kwiberg@webrtc.org
Change-Id: Iea3bb6f3f67b8374c96337b63e8f5aa3e6181012
Reviewed-on: https://chromium-review.googlesource.com/554611
Reviewed-by: Henrik Kjellander <kjellander@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#18821}
This refactoring takes a careful approach to avoid rushing the change:
* stub headers are left in all the old locations of webrtc/base
* existing GN targets are kept and now just forward to the moved ones
using public_deps.
The only exception to the above is the base_java target and its .java files,
which were moved to webrtc/rtc_base right away since it's not possible
to use public_deps for android_library.
To avoid breaking builds, a temporary Dummy.java file was added to
the new intermediate target in webrtc/rtc_base:base_java as well to avoid
hitting a GN assert in the android_library template.
The above approach should make the transition smooth without breaking
downstream.
A helper script was created (https://codereview.webrtc.org/2879203002/)
and was run like this:
stub-headers.py -s webrtc/base -d webrtc/rtc_base -i 7634
stub-headers.py -s webrtc/base/numerics -d webrtc/rtc_base/numerics -i 7634
Fixed invalid header guards in the following files:
webrtc/base/base64.h
webrtc/base/cryptstring.h
webrtc/base/event.h
webrtc/base/flags.h
webrtc/base/httpbase.h
webrtc/base/httpcommon-inl.h
webrtc/base/httpcommon.h
webrtc/base/httpserver.h
webrtc/base/logsinks.h
webrtc/base/macutils.h
webrtc/base/nattypes.h
webrtc/base/openssladapter.h
webrtc/base/opensslstreamadapter.h
webrtc/base/pathutils.h
webrtc/base/physicalsocketserver.h
webrtc/base/proxyinfo.h
webrtc/base/sigslot.h
webrtc/base/sigslotrepeater.h
webrtc/base/socket.h
webrtc/base/socketaddresspair.h
webrtc/base/socketfactory.h
webrtc/base/stringutils.h
webrtc/base/testbase64.h
webrtc/base/testutils.h
webrtc/base/transformadapter.h
webrtc/base/win32filesystem.h
Added new header guards to:
sslroots.h
testbase64.h
BUG=webrtc:7634
NOTRY=True
NOPRESUBMIT=True
R=kwiberg@webrtc.org
Review-Url: https://codereview.webrtc.org/2877023002 .
Cr-Commit-Position: refs/heads/master@{#18816}
