I've been talking with mobile folks more. It's pretty neat and I'm learning a lot about mobile considerations which I previously never thought about. Power utilization of the radio link (http://www.stevesouders.com/blog/2011/09/21/making-a-mobile-connection/) comes up fairly often.

The Qualcomm solution is disappointing to me since "when the page is done loading" is such a horribly vague heuristic. And we're throwing away a lot of potential performance gains from connection reuse.

The root problem as I originally understood if from the article is that the client sending FINs may keep the radio link powered up longer. Well, the obvious solution to me is to just delay sending FINs on sockets that have timed out until you're going to send other data that would also use the radio link anyway: http://code.google.com/p/chromium/issues/detail?id=101820.

Simple tweak, but hopefully it'll make a big difference to mobile browser power utilization, without the horrible perf consequences of other strategies that aggressively close the connection. The open question to me is how costly is the power utilization of the radio link if the server closes the socket (sends a FIN to the client, thereby re-powering its radio link). This varies depending on how long servers allow sockets to stay idle before closing them down. And it might cause the radio link to wake up multiple times just to service FINs. Ugh. There are obvious mitigation strategies to counter this (lower client-side idle socket timeouts and being willing to wake up the radio link once in order to send out a bunch of FINs simultaneously).
Shared publiclyView activity