Hi David, Thanks for your answer. Please see my comments below.
On Mon, Jun 24, 2013 at 3:47 PM, David Jaša <dj...@redhat.com> wrote: > 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@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
