diff options
| author | jar@chromium.org <jar@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98> | 2013-06-21 07:50:57 +0000 |
|---|---|---|
| committer | jar@chromium.org <jar@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98> | 2013-06-21 07:50:57 +0000 |
| commit | ee77da87927d04c8bcefb41098207ae3700a9006 (patch) | |
| tree | 9ff1394c3c43d671fe73eec2e38ef1a812a20508 /net/quic | |
| parent | b42f8d9072bbabbcb5d04042fe4334f1fd4bff6a (diff) | |
| download | chromium_src-ee77da87927d04c8bcefb41098207ae3700a9006.zip chromium_src-ee77da87927d04c8bcefb41098207ae3700a9006.tar.gz chromium_src-ee77da87927d04c8bcefb41098207ae3700a9006.tar.bz2 | |
Set receive buffer size, and comment about possible setting of send buffer.
BUG=252051
r=rch@chromium.org
Review URL: https://chromiumcodereview.appspot.com/16999008
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@207753 0039d316-1c4b-4281-b951-d872f2087c98
Diffstat (limited to 'net/quic')
| -rw-r--r-- | net/quic/quic_stream_factory.cc | 20 |
1 files changed, 20 insertions, 0 deletions
diff --git a/net/quic/quic_stream_factory.cc b/net/quic/quic_stream_factory.cc index ca4d3cb..0d0f731 100644 --- a/net/quic/quic_stream_factory.cc +++ b/net/quic/quic_stream_factory.cc @@ -6,6 +6,7 @@ #include <set> +#include "base/logging.h" #include "base/message_loop.h" #include "base/message_loop/message_loop_proxy.h" #include "base/rand_util.h" @@ -374,6 +375,25 @@ QuicClientSession* QuicStreamFactory::CreateSession( net_log.net_log(), net_log.source()); socket->Connect(addr); + // We should adaptively set this buffer size, but for now, we'll use a size + // that is more than large enough for a 100 packet congestion window, and yet + // does not consume "too much" memory. If we see bursty packet loss, we may + // revisit this setting and test for its impact. + const int32 kSocketBufferSize(kMaxPacketSize * 100); // Support 100 packets. + socket->SetReceiveBufferSize(kSocketBufferSize); + // TODO(jar): What should the UDP send buffer be set to? If the send buffer + // is too large, then we might(?) wastefully queue packets in the OS, when + // we'd rather construct packets just in time. We do however expect that the + // calculated send rate (paced, or ack clocked), will be well below the egress + // rate of the local machine, so that *shouldn't* be a problem. + // If the buffer setting is too small, then we will starve our outgoing link + // on a fast connection, because we won't respond fast enough to the many + // async callbacks to get data from us. On the other hand, until we have real + // pacing support (beyond ack-clocked pacing), we get a bit of adhoc-pacing by + // requiring the application to refill this OS buffer (ensuring that we don't + // blast a pile of packets at the kernel's max egress rate). + // socket->SetSendBufferSize(????); + QuicConnectionHelper* helper = new QuicConnectionHelper( base::MessageLoop::current()->message_loop_proxy().get(), clock_.get(), |