Temporarily increase DTLS buffer size to 2.
It's not expected this will make a difference, since the packet should
be read from the queue if possible as soon as it's added to it.
But we're doing this as an added precaution in case we overlooked
something. See linked bug.
Bug: chromium:1063834
Change-Id: I7a3a6d86a97683cbcbeed5ef1aaa8090cf6bf8c0
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/172661
Commit-Queue: Taylor <deadbeef@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#30990}
diff --git a/p2p/base/dtls_transport.cc b/p2p/base/dtls_transport.cc
index 5ae61ca..1b7a660 100644
--- a/p2p/base/dtls_transport.cc
+++ b/p2p/base/dtls_transport.cc
@@ -37,7 +37,10 @@
// Maximum number of pending packets in the queue. Packets are read immediately
// after they have been written, so a capacity of "1" is sufficient.
-static const size_t kMaxPendingPackets = 1;
+//
+// However, this bug seems to indicate that's not the case: crbug.com/1063834
+// So, temporarily increasing it to 2 to see if that makes a difference.
+static const size_t kMaxPendingPackets = 2;
// Minimum and maximum values for the initial DTLS handshake timeout. We'll pick
// an initial timeout based on ICE RTT estimates, but clamp it to this range.
@@ -99,6 +102,9 @@
}
bool StreamInterfaceChannel::OnPacketReceived(const char* data, size_t size) {
+ if (packets_.size() > 0) {
+ RTC_LOG(LS_WARNING) << "Packet already in queue.";
+ }
bool ret = packets_.WriteBack(data, size, NULL);
if (!ret) {
// Somehow we received another packet before the SSLStreamAdapter read the
