Just some remark on 1). Responding to an HTTP request is not the same as closing an TCP/IP connection. With keep-alive enabled browsers the underlying TCP/IP connection will be reused for the next request (which is scheduled immediately according to the spec).
Regards, Steve Am 12.04.2012 um 14:51 schrieb Peter Saint-Andre: > Of interest. > > - -------- Original Message -------- > Subject: 2.0 and Radio Impacts/battery efficiency > Resent-Date: Thu, 12 Apr 2012 08:53:01 +0000 > Resent-From: [email protected] > Date: Thu, 12 Apr 2012 10:52:18 +0200 > From: Salvatore Loreto <[email protected]> > To: HTTP Working Group <[email protected]> > > > > Hi there, > > here a good read about "Optimizing Downloads for Efficient Network Access" > http://developer.android.com/training/efficient-downloads/efficient-network-access.html > > the major points are > > 1) reducing the number of connections is a MUST as each new network > connection is extremely expensive > from a Radio/Battery prospective > > It is also worth to add that the server-initiated closing of idle > connection is also something to avoid. > So if the client keeps the connection open longer, then the > specification has to mandate servers to keep > the connection open for very long. > > > 2) the ping frequency is also very important: > /"An app that pings the server every 20 seconds, just to acknowledge > that the app is running and visible to the user, will keep the radio > powered on indefinitely" > / > > 3) also Prefetching data need some consideration from the radio > prospective as Prefetching data (on a wireless connection) > may cost money but for sure has a cost from a battery prospective > > > cheers > Sal > > - -- > Salvatore Loreto, PhD > www.sloreto.com >
signature.asc
Description: Message signed with OpenPGP using GPGMail
