summaryrefslogtreecommitdiffstats
path: root/chrome/browser/net/preconnect.h
Commit message (Collapse)AuthorAgeFilesLines
* Eliminate HttpStreamHandle. The name confused me.willchan@chromium.org2010-09-211-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | HttpStreamHandle was a combination of an HttpStream and a scoped_ptr<ClientSocketHandle>. This let it manage the transport socket if so desired. I think that the HttpStream should be in charge of managing this. * HttpBasicStream should always release it to the pool when done, but perhaps disconnect it first. * HttpPipelinedStream (or whatever we name it) should know not to disconnect the transport socket or whatever. It should return it to the pipeline stream manager. * SPDY subtypes of HttpStream do not manage the transport socket. They let the SpdySession handle it. Since the ownership pattern varies based on the HttpStream subtype, I think letting a HttpStreamHandle class perhaps control it is confusing. It's better for the subtype to know what it's supposed to do. There was only one hangup here, the HttpProxyClientSocket, since it might need to Disconnect() and then re-Connect() the transport socket. It was using an HttpBasicStream, which, with my change, would own the transport socket handle. I fixed this by making the HttpProxyClientSocket create an HttpStreamParser instead, which does not own the transport socket handle. Review URL: http://codereview.chromium.org/3133029 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@60117 0039d316-1c4b-4281-b951-d872f2087c98
* Update the Preconnect logic to use the new HttpStreamFactory formbelshe@chromium.org2010-09-031-20/+33
| | | | | | | | | | | | | | | | creating connections rather than doing it manually. With this update, I believe we no longer need to avoid preconnects through proxies. The new logic can handle that case. Also updated the predictor_api slightly for the next wave of work. BUG=none TEST=existing Review URL: http://codereview.chromium.org/3226011 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@58464 0039d316-1c4b-4281-b951-d872f2087c98
* Reland 54771 (and 54795) To enable TCP Preconnection by defaultjar@chromium.org2010-08-061-5/+19
| | | | | | | | | | | | | | | | | | | | | | | I pulled out the code to update the socket connectivity stats. I added defensive code which should preclude the crash that was reported on the stability bot. I added a second call to update the stats from ~ClientSocketHandle to ensure that we updated the related ClientSocket when we are torn down. As noted in the original checkin: Enable speculative preconnection by default Added histogram to track preconnection utilization (vs waste). BUG=42694 r=mbelshe Review URL: http://codereview.chromium.org/3050040 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@55197 0039d316-1c4b-4281-b951-d872f2087c98
* Revert 55071 - Reland 54771 (and 54795) To enable TCP Preconnection by defaultdhollowa@chromium.org2010-08-051-19/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Leaks reported with this CL. http://build.chromium.org/buildbot/memory/builders/Linux%20Heapcheck/builds/6130/steps/heapcheck%20test:%20net/logs/stdio Eg. Leak of 24 bytes in 1 objects allocated from: @ 84aece net::SSLClientSocketNSS::BufferRecv @ 84b161 net::SSLClientSocketNSS::DoTransportIO @ 84ca1f net::SSLClientSocketNSS::DoHandshakeLoop @ 84ca6b net::SSLClientSocketNSS::OnHandshakeIOComplete @ 84cadc net::SSLClientSocketNSS::OnRecvComplete @ 84cbb0 net::SSLClientSocketNSS::BufferRecvComplete @ 84ea4b void DispatchToMethod @ 84ea7b CallbackImpl::RunWithParams @ 4b3a10 CallbackRunner::Run @ 853e7e net::TCPClientSocketLibevent::DoReadCallback @ 85426f net::TCPClientSocketLibevent::DidCompleteRead @ 856a5c net::TCPClientSocketLibevent::ReadWatcher::OnFileCanReadWithoutBlocking @ 93d8fd base::MessagePumpLibevent::FileDescriptorWatcher::OnFileCanReadWithoutBlocking @ 93d966 base::MessagePumpLibevent::OnLibeventNotification @ 9da639 event_process_active @ 9da923 event_base_loop @ 93dfd0 base::MessagePumpLibevent::Run @ 8f2873 MessageLoop::RunInternal @ 8f2893 MessageLoop::RunHandler @ 8f2938 MessageLoop::Run @ 44b7f9 TestCompletionCallback::WaitForResult @ 6a1ee6 SSLClientSocketTest_ConnectMismatched_Test::TestBody @ 961831 testing::Test::Run @ 965026 testing::internal::TestInfoImpl::Run @ 96515c testing::TestCase::Run @ 965bbe testing::internal::UnitTestImpl::RunAllTests @ 965d35 testing::UnitTest::Run @ 4a4bf7 TestSuite::Run @ 4a3b6d main @ 2adff5bb11c4 __libc_start_main Suppression: { <insert_a_suppression_name_here> Heapcheck:Leak fun:net::SSLClientSocketNSS::BufferRecv fun:net::SSLClientSocketNSS::DoTransportIO fun:net::SSLClientSocketNSS::DoHandshakeLoop fun:net::SSLClientSocketNSS::OnHandshakeIOComplete fun:net::SSLClientSocketNSS::OnRecvComplete fun:net::SSLClientSocketNSS::BufferRecvComplete fun:void DispatchToMethod fun:CallbackImpl::RunWithParams fun:CallbackRunner::Run fun:net::TCPClientSocketLibevent::DoReadCallback fun:net::TCPClientSocketLibevent::DidCompleteRead fun:net::TCPClientSocketLibevent::ReadWatcher::OnFileCanReadWithoutBlocking fun:base::MessagePumpLibevent::FileDescriptorWatcher::OnFileCanReadWithoutBlocking fun:base::MessagePumpLibevent::OnLibeventNotification fun:event_process_active fun:event_base_loop fun:base::MessagePumpLibevent::Run fun:MessageLoop::RunInternal fun:MessageLoop::RunHandler fun:MessageLoop::Run fun:TestCompletionCallback::WaitForResult fun:SSLClientSocketTest_ConnectMismatched_Test::TestBody fun:testing::Test::Run fun:testing::internal::TestInfoImpl::Run fun:testing::TestCase::Run fun:testing::internal::UnitTestImpl::RunAllTests fun:testing::UnitTest::Run fun:TestSuite::Run fun:main fun:__libc_start_main } I added defensive code in ClientSocketHandle::ReleaseSocket(), which should preclude the crash that was reported on the stability bot. I added a second call to ReleaseSocket() from ~ClientSocketHandle to ensure that we updated the related ClientSocket when we are torn down. r=mbelshe Review URL: http://codereview.chromium.org/3071022 TBR=jar@chromium.org git-svn-id: svn://svn.chromium.org/chrome/trunk/src@55090 0039d316-1c4b-4281-b951-d872f2087c98
* Reland 54771 (and 54795) To enable TCP Preconnection by defaultjar@chromium.org2010-08-051-5/+19
| | | | | | | | | | | | | | | I added defensive code in ClientSocketHandle::ReleaseSocket(), which should preclude the crash that was reported on the stability bot. I added a second call to ReleaseSocket() from ~ClientSocketHandle to ensure that we updated the related ClientSocket when we are torn down. r=mbelshe Review URL: http://codereview.chromium.org/3071022 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@55071 0039d316-1c4b-4281-b951-d872f2087c98
* Revert 54771 - Enable speculative preconnection by defaultjar@chromium.org2010-08-041-19/+5
| | | | | | | | | | | | | | Added histogram to track utilization (vs waste). [The stability bot was reporting problems, so I'm reverting] r=mbelshe Review URL: http://codereview.chromium.org/3026038 TBR=jar@chromium.org Review URL: http://codereview.chromium.org/3090011 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@54930 0039d316-1c4b-4281-b951-d872f2087c98
* Enable speculative preconnection by defaultjar@chromium.org2010-08-031-5/+19
| | | | | | | | | Added histogram to track utilization (vs waste). r=mbelshe Review URL: http://codereview.chromium.org/3026038 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@54771 0039d316-1c4b-4281-b951-d872f2087c98
* Support both preconnection, and pre-resolution for subresourcesjar@chromium.org2010-07-281-3/+9
| | | | | | | | | | | | | | | With this change, both preconnection and preresolution are enabled when the --enable-preconnection flag is turned on. I'm expecting to enable this feature by default soon, so as to better tune the parameters. BUG=42694 r=mbelshe Review URL: http://codereview.chromium.org/3032014 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@54044 0039d316-1c4b-4281-b951-d872f2087c98
* `#pragma once` for app, base, chrome, gfx, ipc, net, skia, viewsthakis@chromium.org2010-07-261-0/+1
| | | | | | | | | BUG=50273 TEST=everything still builds, build is 10% faster on windows, same speed on mac/linux TBR: erg git-svn-id: svn://svn.chromium.org/chrome/trunk/src@53716 0039d316-1c4b-4281-b951-d872f2087c98
* Avoid preconnect (and pre-resolution) when proxy MIGHT be presentjar@chromium.org2010-07-091-0/+10
| | | | | | | | | | | | | | | | | | | This change detects if there is a chance that a proxy MIGHT be used to perform a connection, and if so, it avoids doing any speculative preconnections, or speculative DNS pre-resolution. For testing purposes, a flag is provided to avoid this probe for proxy status. If you enable --preconnect-despite-proxy then preconnection will take place (as appropriate) even if there is a chance that a proxy might be used for connections to some hosts. BUG=47906 r=eroman Review URL: http://codereview.chromium.org/2871038 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@52016 0039d316-1c4b-4281-b951-d872f2087c98
* Do speculative preconnection based on network traffic (not just DNS)jar@chromium.org2010-06-231-2/+2
| | | | | | | | | | | | This rev also handles the triple of scheme/host/port for recording both referrers and speculative connections, so that we can soon support SSL warming as well as "mere" TCP/IP preconnection. r=mbelshe Review URL: http://codereview.chromium.org/2563004 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@50563 0039d316-1c4b-4281-b951-d872f2087c98
* Support speculative pre-connection to search URLsjar@chromium.org2010-05-181-0/+40
Implement several flavors of TCP/IP speculative preconnection under a command line flag (not yet on by default). The first area of preconnection takes place when a user types a query into the omnibox, as we preconnect to the search service when the omnibox suggests it is going to do a search. The second area involves subresources, such as images. When a navigation takes place, and we've seen navigations to that domain/port before, and the history-based probabability that we'll need to make a connection to a second site (host/port) is sufficiently large, then we preconnect to that second site while we are still connecting to the primary site (and before we've gotten content from the primary site. We also fall-back to mere DNS pre-resolution of subresource hostnames when the probability of a connection to the subresource is not high enough. BUG=42694 r=pkasting,willchan,mbelshe Review URL: http://codereview.chromium.org/1585029 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@47479 0039d316-1c4b-4281-b951-d872f2087c98
generated by cgit v1.1 at 2025-02-14 11:44:58 +0000