This change makes WebRTC no longer stop sending video when we receive an
EWOULDBLOCK error from the operating system. This was previously
causing calls on a slow link (where the first hop is slow) to rapidly
oscillate between starting and stopping video.
We still do need to stop sending packets if there is no known good
connection we can use for that. We used to generate a synthetic
EWOULDBLOCK error in that case. This CL replaces it with a different
code (ENOTCONN); EWOULDBLOCK no longer stops the stream but ENOTCONN
does.
I've updated all the places where we seemed to be generating EWOULDBLOCK
for reasons other than some buffer been full; please give it a thorough
look in case I missed something.
R=pthatcher@webrtc.org
Review URL: https://codereview.webrtc.org/2192963002 .
Cr-Commit-Position: refs/heads/master@{#13566}
Every message will now be traced with the location from which it was
posted, including function name, file and line number.
This CL also writes a normal LOG message when the dispatch took more
than a certain amount of time (currently 50ms).
This logging should help us identify messages that are taking
longer than expected to be dispatched.
R=pthatcher@webrtc.org, tommi@webrtc.org
Review URL: https://codereview.webrtc.org/2019423006 .
Cr-Commit-Position: refs/heads/master@{#13104}
Add sent_ping_requests, recv_ping_responses to ConnectionInfo.
recv_ping_responses_ will be incremented when OnConnectionRequestResponse() is called.
ent_ping_requests_ will be incremented when OnConnectionRequestSent() is called.
BUG=webrtc:5695
Review-Url: https://codereview.webrtc.org/1940493002
Cr-Commit-Position: refs/heads/master@{#13001}
If the remote side sends a candidate with the same address and port with an existing candidate,
but with a new ufrag and pwd, the local client will create a new connection from it
and destroy the old connection with the same remote address.
BUG=webrtc:5915
Review-Url: https://codereview.webrtc.org/2018693002
Cr-Commit-Position: refs/heads/master@{#13000}
No operator== that accepts one unique_ptr<T> and one T*. No implicit
conversion to bool. No rtc_make_scoped_ptr function.
BUG=webrtc:5520
Review URL: https://codereview.webrtc.org/1803833002
Cr-Commit-Position: refs/heads/master@{#12048}
Chromium reported errors when building libjingle_nacl due to some methods used virtual instead of override when they were overriding the base class. My guess is that when one method starts using override, all other in the same class must too.
R=tommi@webrtc.orgTBR=pthatcher@webtrc.org
BUG=4173
Review URL: https://codereview.webrtc.org/1589563003 .
Cr-Commit-Position: refs/heads/master@{#11251}
To reduce the risk of future mistakes when connecting Ports, Port::OnSentPacket was made pure virtual to ensure that new implementations take care of it.
BUG=4173
R=pthatcher@webrtc.org
Review URL: https://codereview.webrtc.org/1577873003 .
Cr-Commit-Position: refs/heads/master@{#11247}
If the local port and the remote candidate's protocols do not match,
do not even try to pair them.
This avoids printing out confusing logs like
"Attempt to change a remote candidate..." in p2ptransportchannel
when two remote candidates have the same port number but different
protocols.
BUG=
R=pthatcher@webrtc.org
Review URL: https://codereview.webrtc.org/1516613002 .
Cr-Commit-Position: refs/heads/master@{#11034}
In tcp only call:
Tested with hangout.
Tested with firefox.
To test firefox, goto about:config, search for media.peerconnection.ice.tcp and turn it on.
Existing test case should be suffice to cover this.
R=juberti@google.comTBR=jubert@webrtc.org
BUG=webrtc:3849
Review URL: https://codereview.webrtc.org/1217463004 .
Cr-Commit-Position: refs/heads/master@{#10683}
Since the TCPConnection has never been connected, they are not scheduled for ping hence will never be detected.
Also fix the case when reconnect fails, as it has become READABLE before, it also will not be deleted.
BUG=webrtc:4936
R=pthatcher@webrtc.org
Review URL: https://codereview.webrtc.org/1307083002 .
Cr-Commit-Position: refs/heads/master@{#9782}
During the reconnection phase, EWOULDBLOCK has been returned to upper layer which stops the sending of video stream.
BUG=webrtc:4930
R=pthatcher@webrtc.org
Review URL: https://codereview.webrtc.org/1288553010 .
Cr-Commit-Position: refs/heads/master@{#9767}
The IceEndpointType has the format of <local_endpoint>_<remote_endpoint>. It is recorded on the BestConnection when we have the first OnTransportCompleted signaled.
BUG=webrtc:4918
R=pthatcher@webrtc.org
Review URL: https://codereview.webrtc.org/1277263002 .
Cr-Commit-Position: refs/heads/master@{#9737}
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}
