Announcing MXHR4AS3: Multipart/mixed-file download by Flash clients
After having read about and experimented with Digg’s MXHR concept and DUI.Stream, I have now implemented the very same thing for ActionScript 3. In my tests it really shows a performance-boost over conventional queued download.
Introduction
I have implemented the MXHR client to be able to use multiple concurrent http-streams to load the files even faster. This is done in order to make sure that the MXHR client can have the same advantage as conventional downloading, where concurrent streams perform better than simple queued streams.
The MXHR client is implemented pretty straight-forward in AS3 with 3 simple classes – MXHR, MXHRFile and MXHREvent. The serverside implementation, that I choose, was in PHP, and since the folks at Digg did not provide one such sample implementation, I did my own. It is done in PHP 5 through a single class MXHR taking file names and building a aggregated response (in conformance with specifications of course) – and it supports caching.
Results
Some example download times by my tests:
| Method | Streams | Uncached load time | Cached load time |
|---|---|---|---|
| Conventional | 1 | 37094 ms | 15854 ms |
| 8 | 5319 ms | 3126 ms | |
| MXHR4AS3 | 1 | 4386 ms | 1473 ms |
| 8 | 3695 ms | 1421 ms |
Try it out for yourself here:
- Conventional single-threaded download
- Conventional multi-threaded download
- MXHR-based single-threaded download
- MXHR-based multi-threaded download
As you can see, when the files are cached there is almost no difference between MXHR-based single- or multi-threaded download. And both are significantly faster (both cached and uncached) compared to either type of conventional download.
Source
I will need to do a little bit of further testing and clean-up before I put the full source-code up for download, but when I do, it will be on Google Code Bitbucket under the site license.
Related posts:
Category: API, AS3, Trends 6 comments »
September 6th, 2009 at 14:12
am i the first to comment.. and say how cool this is?
the demo is very impressive. do you think it would help in delivring mp3s embedded in swf format faster? if so then we could convert mp3′s to swf and pipe around music and beats faster
seems like the next logical step is to build a class manager
hit us up with the code so we can continue this cool innovation of yours :)
john
September 6th, 2009 at 17:06
Hi John,
Thanks for your interest.
I don’t see the purpose of wrapping MP3′s in SWF’s, because the most interesting thing about sounds as MP3′s is, that they can play progressively – i.e. while downloading. If wrapped in a SWF it would still be possible but harder to achieve.
And the above concept, that I have constructed, does not allow for progressive download of the individual files – only when the entire file (each part of the response) is in, it is returned to the requester.
The advantage only shows when loading many files – especially small files. For instances loading picture thumbnails for a gallery, profile images for a forum post, and similar situations. For larger files the convetional load is just as good and might even be better, as it gives better control over caching etc.
I will however make sure to upload the source as soon as possible :)
September 6th, 2009 at 22:09
hi
after i woke up and thought about it more i understand why mp3 doesnt make much sense. this is more about packaging together multiple files into one request. so it would make better sense for something like multiple json feeds/images that a flash app needs to initialize/load config settings from.
why not just use zip format then? have something like a zip client in actionscript that would unpack the files you need..this would have the added advantage of compression. do you know of any such solution for flash?
in anycase very cool work..i spent some time sniffing things out with charles and you do indeed package multiple gifs in one request..demo is most impressive
September 7th, 2009 at 11:53
Hi John,
Compression is outside the scope of this and can easily be added on top of this. Gzip could be added by your web server and is supported by Flash built-in and completely transparent. Simply set up e.g. Apache to compress the response and Flash will automatically decompress once received before passing the response back to your handler.
MXHR have another benefit besides from packing stuff together in a single request – it is also streaming, and you could actually load one small file and one large file in said order and in Flash you could the display the small file as soon as it was loaded – without waiting until the large file was downloaded as well. If this wasn’t possible, this concept wouldn’t have been as interesting.
The “packaging” method, that I used is mime and the content-type “multipart/mixed”. This is a documented way of transferring multiple responses in a single stream somewhat like attachments in emails. I felt no need to re-invent neither packaging nor compression and simply used existing best-practices.
I hope you see where I’m going :)
September 7th, 2009 at 20:49
yes i understand better now thank you. a usecase would be an image gallery where you would want the smaller thumbnail images to stream in first, then the larger ones later . well i guess in that case they would be requested on demand
i had no idea flash has gzip built into it..thats very cool to know..or maybe its the browser that has it
in anycase looking forward to the code
john
October 9th, 2009 at 11:19
[...] finally got the time to clean up the code for MXHR4AS3 – an implementation of the Digg-introduced concept of requesting several files from the [...]