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.

Reply via email to