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

[Fedor Lyakhov]

Hans,

Thanks for the comments and clarifications! OK, I'll start with more simple
solution of 'local/remote' detection first.

As for gsettings - I see your point, this will solve the issue for Gnome3
as requested. But I think this is too limited - e.g. what if KDE5 wants
this in future?



On Mon, Jun 24, 2013 at 5:54 PM, Hans de Goede <hdegoede at redhat.com> wrote:

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


-- 
Best regards,
Fedor
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/spice-devel/attachments/20130624/175f2890/attachment-0001.html>