<div dir="ltr"><br><div class="gmail_extra">Hi David,<br><br></div><div class="gmail_extra">Thanks for your answer. Please see my comments below.<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Jun 24, 2013 at 3:47 PM, David Jaša <span dir="ltr"><<a href="mailto:djasa@redhat.com" target="_blank">djasa@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Fedor,<br>
<br>
I'd personally prefer to:<br>
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)<br>
2) set the options on-the fly as the conditions allow to get at the right position in b/w-saving <---> cpu saving scale<br>
<br>
The reason for this preference of mine is two-fold:<br>
* idle gigabit or 100Mbps LAN may be closer to localhost behaviour than WAN behaviour, especially with decreasing stream resolution<br>
* such behaviour would be consistent with the rest of the spice protocol<br></blockquote><div><br>[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).<br>
</div><div><br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
I'm also not sure if I follow what you want to do with an agent:<br>
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...<br>

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<br>

<br></blockquote><div><br>[FL] I do understand all this. Sorry for my previous bloated e-mail giving you wrong picture of what I'm suggesting.<br></div><div>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:<br>
</div><div>1. D-Bus (low-level API, or GLib bindings)<br></div><div>2. Raw socket with custom protocol (similar to vdagent <-> vdagentd)<br><br></div><div>Personally I'd prefer D-Bus, since looks like this is the best interface for freedesktop-based environments.<br>
<br></div><div>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).<br>
<br></div><div>If D-Bus is approved, I can think of enhancing vdagent<->vdagentd communication from socket to D-Bus as well.<br><br><br></div>-Fedor<br></div></div></div>