Hi,
On Ne, 2014-01-12 at 18:29 +0100, Marc-André Lureau wrote:
> This channel provides a webdav server (rfc4918). This allows various
> guest or remote system that support webdav to access a folder shared by
> the client (some agent can be used to proxy the requests on a local port
> for example). The webdav server may also be accessed by an hypervisor as
> a remote filesystem interface, which can then be accessed by the guest
> via other means (fs/fat emulation, mtp device, etc)
>
> Due to the usage of a single channel stream and the need for concurrent
> requests, webdav clients streams are multiplexed. Each client stream is
> framed within 64k max messages (in little-endian)
>
> int64 client_id
> uint16 size
> char data[size]
>
> A new client_id indicates a new connection. A new communication stream
> with the webdav server should be started. A client stream message of
> size 0 indicates a disconnection of client_id. This multiplexed
> communication happens over the channel "data" message.
>
> Only when the port is opened may the communication be started.
> A closed port event should close all currently known multiplexed
> connections.
>
> Why WebDAV?
>
> webdav is supported natively by various OS for a long time (circa
> Windows XP). It has several open-source implementations and a variety of
> tools exist. A webdav implementation can be tested and used without a
> Spice server or any virtualization (this also permit sharing the
> implementation with other projects in the future, such as GNOME). It is
> an IETF open standard and thus thoroughly specified.
>
> The basic requirements for an efficient remote filesystem are provided
> by the standard (pipelining, concurrency, caching, copy/move, partial
> io, compression, locking ...) While other features are easily possible
> via extensions to the protocol (common ones are executable attributes,
> or searching for example).
>
> Given the requirements, and the popularity of http/webdav, I believe it
> is the best candidate for Spice remote filesystem support.
>
> Other alternatives (adhoc, p9, smb2, sftp) have been studied and
> discarded so far since they do not match in term of features or
> requirements.
Do you have a reference to comparison or analysis? Also did you evaluate
use of webdav for on-wire protocol but USB MTP for making the device
visible to the guest? My quick take would be that the big MTP upside is
that it doesn't require Yet Another Guest Tool (virtio-to-http server)
nor user cooperation within the guest (need to specifically navigate to
localhost://port) - the USB stack takes care of plugs/unplugs nicely and
the integration with file managers works just fine. The only downsides
I'm aware of are:
* no qemu code written yet. It was proposed to GSoC 2013 but no work
found its way to qemu tree [1][2]
* bad support in older-than-recent Linux distributions
David
[1] http://qemu-project.org/Google_Summer_of_Code_2013#Add_USB_Media_Transfer_Protocol_emulation_to_QEMU
[2] http://git.qemu-project.org/?p=qemu.git&a=search&h=HEAD&st=commit&s=[Mm][Tt][Pp]&sr=1
> ---
> spice.proto | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/spice.proto b/spice.proto
> index 67b3803..316d287 100644
> --- a/spice.proto
> +++ b/spice.proto
> @@ -1352,6 +1352,9 @@ channel PortChannel : SpicevmcChannel {
> } event;
> };
>
> +channel WebDAVChannel : PortChannel {
> +};
> +
> protocol Spice {
> MainChannel main = 1;
> DisplayChannel display;
> @@ -1363,4 +1366,5 @@ protocol Spice {
> SmartcardChannel smartcard;
> UsbredirChannel usbredir;
> PortChannel port;
> + WebDAVChannel webdav;
> };
_______________________________________________
Spice-devel mailing list
Spice-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/spice-devel