[Spice-devel] Questions regarding Bug 62033 - Means to detect local-only

[Hans de Goede]

Hi,

On 06/24/2013 02:44 PM, Fedor Lyakhov wrote:
>
> Hi David,
>
> Thanks for your answer. Please see my comments below.
>
>
> On Mon, Jun 24, 2013 at 3:47 PM, David Jaša <djasa at redhat.com <mailto:djasa at 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).

Although I agree with doing continuous bandwidth + latency monitoring, this is something which
will not be trivial. I would prefer to see a "simple" local / non local detection too. Low hanging
fruit first.

And since in the future we hope to have 3d pass-through too, this will be useful for determine
settings there too.

Since we sometimes get passed file-descriptors rather then opening sockets our-selves, we cannot
simply check for localhost or some such for local detection. So we will likely need to fallback
to checking if the spice-server and spice-client share a filesystem. One possible way to do
this would be to create a shared memory segment with a unique name from one side and have the
other side also open this. See for example how pulseaudio does this.

This may seem like overkill for just "local" detection, but we will likely want a shared-memory
segment in the future anyways to use to speedup the local use case (by avoiding sending pixmaps
over a socket), so it seems like a good idea to create one now, even if just gets used for
local detection for now.


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

I don't think that any dbus api will be needed the agent can simply change the gsettings for these, and then
gnome-shell will notice the change and react accordingly, at least I assume this is how the control-center
settings work and get applied. Even if I'm wrong about the gsettings bit, there has to be an API between
the control-center and gnome-shell, and rather then inventing a new one it would be good for the agent to
re-use the existing one to talk to gnome-shell / gsd

Regards,

Hans