Re: [Qemu-devel] [PATCH] An alternative http protocol

[Alexander Graf]

On 10.04.2009, at 03:56, Nolan wrote:

> Alexander Graf's posting of his HTTP protocol for block devices  
> prompted
> me to finally cleanup and submit my implementation of the same  
> thing, so
> that both may be considered and compared.

Phew - I didn't know HTTP backends were this popular :-).

> The most obvious difference is that this implementation uses libneon
> instead of libcurl.

Oh - I didn't even know about libneon before :-o.

> It supports HTTPS, proxies, and HTTP basic auth, though be aware  
> that if
> you pass a URL with credentials on the command line, anyone who can  
> run
> "ps" on the host can see your credentials!

FWIW libcurl supports these too plus FTP and TFTP, though I haven't  
tried it myself. The good thing about the FTP/TFTP support is that it  
should bascially work exactly the same, so libcurl interprets the  
"range" parameter and ends up doing "the right thing" for the  
respective protocols.

> It also supports rounding range request sizes up and a simple 1 entry
> cache, defaulting to 256KB.  This _greatly_ reduces the load on the
> server when using a HTTP cdrom .iso, as well as when using an HTTP  
> image
> as a source for "qemu-img convert".  Without this, booting off an HTTP
> livecd iso results in tens of thousands to hundreds of thousands of  
> 1500
> byte HTTP range requests.

My ultimate goal was to have a background downloader integrated, so  
you could basically run an image on-the-fly, save it to disk and have  
it there once it's done downloading.

This way there's a pretty good chance the "download all" background  
downloading thread might have gotten to the part you actually want to  
read already. Also it might be clever to implement some basic read- 
ahead based on line speed, so if you request 2 sectors at offset n,  
you'd basically download say 20 blocks, giving the AIO return as soon  
as 2 are downloaded.

I don't know how much of this is possible with libcurl, but I was  
hoping it's feasible :-).

So in case you're planning on developing this on, please keep my  
design goals in mind as well. In the end I'd like to get this  
functionally en par with the VMware on-demand execution solution.

Alex