Hi David,
Thanks for your answer. Please see my comments below.
On Mon, Jun 24, 2013 at 3:47 PM, David Jaša <djasa@xxxxxxxxxx> wrote:
[FL] I agree with your points. So implementation will be based on continuous bandwidth and latency monitoring and reporting. This means we'd need a heuristic algorithm to detect a threshold for 'bad' and 'good' connection (and reporting the threshold has been crossed in one or another direction).
[FL] I do understand all this. Sorry for my previous bloated e-mail giving you wrong picture of what I'm suggesting.
Hi Fedor,
I'd personally prefer to:
1) monitor bandwidth and latency continuously - there's a long-standing RFE for it and IIRC Yonit has posted some proof-of-concept patches in recent months (as a part of her streamlining of video streams)
2) set the options on-the fly as the conditions allow to get at the right position in b/w-saving <---> cpu saving scale
The reason for this preference of mine is two-fold:
* idle gigabit or 100Mbps LAN may be closer to localhost behaviour than WAN behaviour, especially with decreasing stream resolution
* such behaviour would be consistent with the rest of the spice protocol
[FL] I agree with your points. So implementation will be based on continuous bandwidth and latency monitoring and reporting. This means we'd need a heuristic algorithm to detect a threshold for 'bad' and 'good' connection (and reporting the threshold has been crossed in one or another direction).
I'm also not sure if I follow what you want to do with an agent:
1) the agent runs in the guest OS and communicates already with the client through using spice means - i.e. agent - virtio-serial/qemu - spice-server - spice client. You shouldn't need to invent any other client <--> agent connection, and I can't get how such thing should help you...
2) agent has no connection of what happens with display, and it has a limited knowledge of network conditions as it handles just a subset of all the traffic. spice-server and spice client actually do have complete picture of what happens on the wire
[FL] I do understand all this. Sorry for my previous bloated e-mail giving you wrong picture of what I'm suggesting.
New functionality for vdagent is required: an interface for applications running at guest OS. In particular, gnome-settings-daemon needs to know whether the connection is good or bad, and toggle animations accordingly. I see following options for interface vdagent<->guest-apps:
1. D-Bus (low-level API, or GLib bindings)
2. Raw socket with custom protocol (similar to vdagent <-> vdagentd)
Personally I'd prefer D-Bus, since looks like this is the best interface for freedesktop-based environments.
This is interface facing users (apps at guest); for internals I'm going to reuse current vdagent<->vdagentd communication mechanism, and vdagentd -virtio-serial/qemu - spice-server (which will provide the actual state, 'good' or 'bad', and report the metrics probably).
If D-Bus is approved, I can think of enhancing vdagent<->vdagentd communication from socket to D-Bus as well.
-Fedor_______________________________________________ Spice-devel mailing list Spice-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/spice-devel