It looks like org.apache.http tries to use persistent connections by default, judging by the existence of a KeepAlive property. I think you can create an HttpConnection and then issue multiple requests on that same connection. What I don't know is whether or not it automatically re-establishes the connection if/when it goes down.
On Mar 3, 12:04 pm, Nathan <[email protected]> wrote: > Seth, > > I download a lot of small files over HTTP, and I am very much > interested in making it more efficient. It's working okay, but there > is room for improvement. > > Neither zip files nor your MTP/IP technology because I do not control > the servers. > > In many cases, the host name is constant so persistent HTTP would > help. Do you have some examples? If you have a library that automates > this sort of thing, sure I'll buy it. The parallel transfers is also > possibly helpful. > > Nathan > > On Mar 3, 8:36 am, Seth Noble <[email protected]> wrote: > > > > > John, > > > The lag time for file requests is definitely a killer, and it varies > > greatly depending on the protocol being used. FTP is one of the > > worst as it can take a dozen round-trips to open a session then > > half-a-dozen or more round-trips to start each file. Regular HTTP > > is better, but not a lot. When latency is approaching 500ms (not > > uncommon on a mobile link), that's several seconds of down-time > > between each file. > > > The downside to zipping is the extra CPU and memory costs at both > > ends. Of course, for images, you should be able to disable > > compression (store-only) and save a lot of CPU cycles. > > > Here are some other options: > > > Persistent HTTP: Normally HTTP sets up a new TCP connection for > > every file, which is almost as bad as FTP. But if you can use > > persistent HTTP, then it only costs you about two round-trips > > between files. This doesn't help with carrier proxies mangling your > > images, though faking the mime types might. > > > Parallel transfers: Downloading two or three files at a time will > > usually help overcome the delay-between-files issue. It increases > > the load at the server side, but that is usually only a problem when > > the total network speed exceeds 50 megabits per second. So that > > shouldn't be an issue for mobile. > > > Obligatory plug: Our own MTP/IP technology reduces the overhead for > > each transfer to just one round-trip, even when starting cold. The > > downside is that the server must also be an MTP/IP application, such > > as our ExpeDat server. > > > Hopefully this helps! > > > Best Regards, > > Seth > > > On Mar 2, 2:52 pm, "Maps.Huge.Info (Maps API Guru)" <[email protected]> > > wrote: > > > > I've been using zip files to move data to Android devices. By > > > combining all the files you need into one zip file, you save on the > > > lag time it takes from the request to the actual file being delivered. > > > Also, for large image files, some carriers alter the resolution of > > > them which reduces the file size but basically kills the image > > > quality. By zipping them, the carrier leaves them alone. > > > > -John Coryat > > > > On Mar 2, 9:59 am, Seth Noble <[email protected]> wrote: > > > > > Is anyone developing an application which needs to move large amounts > > > > of time-sensitive data to or from an Android device? > > > > > My company, "Data Expedition, Inc.", has been experimenting with > > > > transport acceleration on Android and getting several times faster > > > > throughput. But we could really use some practical feedback about > > > > developer needs, particularly with regard to API features. > > > > > We would like to hear from professional developers of commercial > > > > apps with a client-server data model and a need for more speed. > > > > Comments, ideas, and participation in testing are welcome! > > > > > More information about us and our technology can be found > > > > here:http://www.DataExpedition.com/ > > > > > Please contact me via [email protected] > > > > > I am also happy to discuss general mobile networking performance > > > > issues in this thread. We have a number of performance related > > > > technical notes on our website which can be helpful for evaluating > > > > the network performance of any technology: > > > > >http://www.DataExpedition.com/support/notes/ > > > > > -- Seth Noble > > > > Data Expedition, Inc. -- You received this message because you are subscribed to the Google Groups "Android Discuss" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/android-discuss?hl=en.
