1. when an IP is reported by DNS but it doesn't serve any traffic, we shouldn't count failure from that.
2. shared socket mode should should only be true for the case where multiple IPs are resolved and successfully pinged.
3. allow multiple STUN servers now.
Fix a bug in symnat detection. SymNAT will provide the same IP but different port.
If we have more than 1 srflx IP, we'll fail the experiment.
BUG=4576
R=pthatcher@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/51849004
Cr-Commit-Position: refs/heads/master@{#9215}
It was too spammy in the log because we have many code paths that check for responses when it's not a problem that it's not an expected response.
R=glaznev@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/47199004
Cr-Commit-Position: refs/heads/master@{#9212}
Chrome will only see stunprober.h and stunprobercontext.h and link with libstunprober.a.
It has support for shared and non-shared mode. In shared mode, a socket will be used to ping all resolved IPs once. In non-shared mode, each ping will get a new socket.
The thread scheduling will try to run MaybeScheduleStunRequest every 1 ms. When the time is up for next ping, it'll send it out.
BUG=4576
R=pthatcher@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/51729004
Cr-Commit-Position: refs/heads/master@{#9194}
1. Constructors, SetData(), and AppendData() now accept uint8_t*,
int8_t*, and char*. Previously, they accepted void*, meaning that
any kind of pointer was accepted. I think requiring an explicit
cast in cases where the input array isn't already of a byte-sized
type is a better compromise between convenience and safety.
2. data() can now return a uint8_t* instead of a char*, which seems
more appropriate for a byte array, and is harder to mix up with
zero-terminated C strings. data<int8_t>() is also available so
that callers that want that type instead won't have to cast, as
is data<char>() (which remains the default until all existing
callers have been fixed).
3. Constructors, SetData(), and AppendData() now accept arrays
natively, not just decayed to pointers. The advantage of this is
that callers don't have to pass the size separately.
4. There are new constructors that allow setting size and capacity
without initializing the array. Previously, this had to be done
separately after construction.
5. Instead of TransferTo(), Buffer now supports swap(), and move
construction and assignment, and has a Pass() method that works
just like std::move(). (The Pass method is modeled after
scoped_ptr::Pass().)
R=jmarusic@webrtc.org, tommi@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/42989004
Cr-Commit-Position: refs/heads/master@{#9033}
UDP case should not be changed.
Active TCPConnection will initiate Reconnect after OnClose and when Send or Ping fails.
Passive TCPConnection will prune itself as usual as the active side will create a new connection.
The Reconnect could make P2PCT choose a different best_connection in the case where connectivities exist b/w more than 1 Network.
Also, to avoid upper layer triggers ice restart, the WRITE_TIMEOUT caused by the socket disconnection is delayed to give the reconnect mechanism chance to kick in. The timeout event is only fired if the reconnect can't work in 5 sec. If the reconnect, there should be no ICE disconnected state trigger either in active or passive side.
BUG=1926
R=pthatcher@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/31359004
Cr-Commit-Position: refs/heads/master@{#8929}
And add a constructor for creating an uninitialized Buffer of a
specified size.
(I intend to follow up with more Buffer changes, but since it's rather
widely used, the rename is quite noisy and works better as a separate
CL.)
R=tommi@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/48579004
Cr-Commit-Position: refs/heads/master@{#8841}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8841 4adac7df-926f-26a2-2b94-8c16560cd09d
Also fixed the issue when we have an TransportChannelImpl, the socket
option is not preserved.
Since this is a code path that will be modified by bundle (which Peter also has a test case already), we don't need a test case here.
BUG=4374
R=pthatcher@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/42699004
Cr-Commit-Position: refs/heads/master@{#8702}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8702 4adac7df-926f-26a2-2b94-8c16560cd09d
Clang version changed 223108:230914
Details: e144d30..6fdb142/tools/clang/scripts/update.sh
Removes the OVERRIDE macro defined in:
* webrtc/base/common.h
* webrtc/typedefs.h
The majority of the source changes were done by running this in src/:
perl -0pi -e "s/virtual\s([^({;]*(\([^({;]*\)[^({;]*))(OVERRIDE|override)/\1override/sg" `find {talk,webrtc} -name "*.h" -o -name "*.cc*" -o -name "*.mm*"`
which converted all:
virtual Foo() OVERRIDE
functions to:
Foo() override
Then I manually edited:
* talk/media/webrtc/fakewebrtccommon.h
* webrtc/test/fake_common.h
Remaining uses of OVERRIDE was fixed by search+replace.
Manual edits were done to fix virtual destructors that were
overriding inherited ones.
Finally a build error related to the pure virtual definitions of
Read, Write and Rewind in common_types.h required a bit of
refactoring in:
* webrtc/common_types.cc
* webrtc/common_types.h
* webrtc/system_wrappers/interface/file_wrapper.h
* webrtc/system_wrappers/source/file_impl.cc
This roll should make it possible for us to finally re-enable deadlock
detection for TSan on the buildbots.
BUG=4106
R=pbos@webrtc.org, tommi@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/41069004
Cr-Commit-Position: refs/heads/master@{#8596}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8596 4adac7df-926f-26a2-2b94-8c16560cd09d
Mostly, it's about moving constructors and descructors to the .cc
files, so that they won't be inlined everywhere.
The reason this CL is so big is that a lot of code was using
common_types.h without declaring a dependency on webrtc_common, which
broke the build once common_types.h started to depend on
common_types.cc.
BUG=163
R=kjellander@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/26089004
Cr-Commit-Position: refs/heads/master@{#8516}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8516 4adac7df-926f-26a2-2b94-8c16560cd09d
WebRTC binds to individual NICs and listens for incoming Stun packets. Sending stun through this specific NIC binding could make OS route the packet differently hence exposing non-VPN public IP.
The fix here is
1. to bind to any address (0:0:0:0) instead. This way, the routing will be the same as how chrome/http is.
2. also, remove the any all 0s addresses which happens when we bind to all 0s.
BUG=4276
R=juberti@webrtc.org
Committed: https://code.google.com/p/webrtc/source/detail?r=8418
Review URL: https://webrtc-codereview.appspot.com/39129004
Cr-Commit-Position: refs/heads/master@{#8419}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8419 4adac7df-926f-26a2-2b94-8c16560cd09d
WebRTC binds to individual NICs and listens for incoming Stun packets. Sending stun through this specific NIC binding could make OS route the packet differently hence exposing non-VPN public IP.
The fix here is
1. to bind to any address (0:0:0:0) instead. This way, the routing will be the same as how chrome/http is.
2. also, remove the any all 0s addresses which happens when we bind to all 0s.
BUG=4276
R=juberti@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/39129004
Cr-Commit-Position: refs/heads/master@{#8418}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8418 4adac7df-926f-26a2-2b94-8c16560cd09d
I'm reverting the patch due to compilation issues. It would be great if we could make sure Chromium is ready for the patch before we land it in WebRTC.
As is, we're trying to roll webrtc into Chromium and we can't (this is not the only reason though). I might reland this after the roll, depending on how that goes though.
Here's an example failure:
e:\b\build\slave\win_gn\build\src\jingle\glue\channel_socket_adapter_unittest.cc(77) : error C2259: 'jingle_glue::MockTransportChannel' : cannot instantiate abstract class
due to following members:
'bool cricket::TransportChannel::GetSslCipher(std::string *)' : is abstract
e:\b\build\slave\win_gn\build\src\third_party\webrtc\p2p\base\transportchannel.h(107) : see declaration of 'cricket::TransportChannel::GetSslCipher'
ninja: build stopped: subcommand failed.
> This CL adds an API to the SSL stream adapters and transport channels to get the SSL cipher that was negotiated with the remote peer.
>
> BUG=3976
> R=davidben@chromium.org, juberti@webrtc.org, pthatcher@webrtc.org
>
> Review URL: https://webrtc-codereview.appspot.com/26009004TBR=pthatcher@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/40689004
Cr-Commit-Position: refs/heads/master@{#8282}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8282 4adac7df-926f-26a2-2b94-8c16560cd09d
Failed on Linux_Memcheck bot.
http://chromegw/i/client.webrtc/builders/Linux%20Memcheck/builds/3182
> VirtualSocketServer out-of-order issue with closing TCP sockets
>
> https://webrtc-codereview.appspot.com/41449004 added a TURN TCP
> allocation release test which was disabled as it triggered an assert
> in the turnserver.
>
> This was caused by VirtualSockerServer delivering the last TCP packet
> after closing the connection. Calling
> VirtualSocketServer::SendTcp
> and
> VirtualSocket::Close
> from TestTurnTCPReleaseAllocation led to the following order of
> messages in VirtualSocket::OnMessage:
> MSG_ID_DISCONNECT
> MSG_ID_PACKET
>
> This is out of order and triggers an assert in turnserver.cc since the
> socket from which the message arrives has already been discarded,
> subsequently breaking the test.
>
> In VirtualSocketServer::Disconnect the MSG_ID_DISCONNECT is posted to the
> msg_queue immediately, thus getting ahead of any (slightly delayed)
> actual packets.
>
> Maybe PostAt(network_delay_ + 1, ...) would be better?
>
> Re-enables TestTurnTCPReleaseAllocation.
>
> BUG=
> R=juberti@webrtc.org
>
> Review URL: https://webrtc-codereview.appspot.com/34759004TBR=pthatcher@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/38979004
Cr-Commit-Position: refs/heads/master@{#8280}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8280 4adac7df-926f-26a2-2b94-8c16560cd09d
https://webrtc-codereview.appspot.com/41449004 added a TURN TCP
allocation release test which was disabled as it triggered an assert
in the turnserver.
This was caused by VirtualSockerServer delivering the last TCP packet
after closing the connection. Calling
VirtualSocketServer::SendTcp
and
VirtualSocket::Close
from TestTurnTCPReleaseAllocation led to the following order of
messages in VirtualSocket::OnMessage:
MSG_ID_DISCONNECT
MSG_ID_PACKET
This is out of order and triggers an assert in turnserver.cc since the
socket from which the message arrives has already been discarded,
subsequently breaking the test.
In VirtualSocketServer::Disconnect the MSG_ID_DISCONNECT is posted to the
msg_queue immediately, thus getting ahead of any (slightly delayed)
actual packets.
Maybe PostAt(network_delay_ + 1, ...) would be better?
Re-enables TestTurnTCPReleaseAllocation.
BUG=
R=juberti@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/34759004
Cr-Commit-Position: refs/heads/master@{#8271}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8271 4adac7df-926f-26a2-2b94-8c16560cd09d
Make a few member variables in the Transport class officially const so that it's clear that locking isn't needed for access. There are getters for some of these (e.g. content_name()) that don't have locking or checking, so making the variables const is at least a way to guard against regressions. Also making the clock_ member in overuse_frame_detector.h const for clarity that it doesn't require a lock for access.
No code change.
Review URL: https://webrtc-codereview.appspot.com/35949004
Cr-Commit-Position: refs/heads/master@{#8186}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8186 4adac7df-926f-26a2-2b94-8c16560cd09d
Accept incoming pings before remote answer is set, to reduce connection latency.
Set ICE connection state to 'checking' after setting the remote answer, so that it can transition into 'connected' if the peer reflexive connection is up before any remote candidate is set. See more details in crbug/446908
BUG=4068, crbug/446908
R=juberti@webrtc.org, pthatcher@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/38709004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8141 4adac7df-926f-26a2-2b94-8c16560cd09d
