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

[David Jaša]

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

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

David


Fedor Lyakhov píše v Ne 23. 06. 2013 v 02:26 +0400:
> Hello Zeeshan, Marc-André and other Spice developers,
> 
> I think about implementing a solution for this bug 62033 (
> https://bugs.freedesktop.org/show_bug.cgi?id=62033).
> 
> First of all, need to clarify what is requested and what is really needed
> in this request. Zeeshan suggests as a simple yet acceptable solution for
> vdagent to report 'local-only' connection non-dynamically.. as I understand
> this means reporting only once, at startup (?). I think it isn't enough
> because this connection state may change easily during X session lifetime -
> in general user is free to connect locally and then re-connect from remote
> host, and vise versa. So I propose more generic approach, when vdagent
> reports current connection state dynamically when state is changed. It will
> be up to gnome-settings-daemon to act on this signal and toggle animations
> accordingly.
> 
> If this is acceptable, we need to decide on the interface. I think there
> are 2 appropriate technologies:
> 1. raw socket [or something like this]
> 2. D-Bus
> 
> I'm not an expert in D-Bus and freedesktop in general (good opportunity for
> me to learn!) but looks like it is appropriate to use it here. 2 questions
> arise:
> 1. vdagentd and vdagent daemons already communicate via socket using simple
> homebrew protocol (at least afaik). Probably this was done on purpose. So
> is it true vdagent wants to avoid dependency on D-Bus?
> 2. It seems to better use some higher-level D-Bus bindings (GLib, Qt...)
> instead of its low-level API. So is it acceptable to add a dependency of
> GLib to vdagent? Or are you aware of some other D-Bus bindings to be used
> in vdagent to avoid this extra dependency?
> 
> BTW, reporting of connection state can be implemented independently of the
> actual transport (socket/D-Bus):
> 1. Client app (e.g. gnome-settings-daemon) establishes connection to
> vdagent being a server (e.g. listening at the socket, or providing D-Bus
> interface method RegisterConnectionStateObserver or w/e we name it)
> 2. vdagent sends the state to registered clients (e.g. D-Bus signal); and
> continues to do so each time the state is changed.
> So we can even have 2 back-ends for this (additional work, unfortunately).
> 
> And last question: while this isn't needed on Windows version of vdagent
> right now, additional use cases of this vdagent interface in guest
> userspace may arise [e.g. I'm thinking about remote media engine provided
> by spice client]. So I think we should target for similar extendable
> interface at both Windows and Linux guests (as much as possible). I haven't
> looked in vdagent for Windows code yet but guess D-Bus won't be the best
> choice there (while D-Bus reportedly works on Windows as well...).
> Something like socket and D-Bus and native DCOM would be the best and
> future-proof.. What do you think?
> 
> [Note: I haven't talked about implementation of new messages between
> vdagent and vdagentd, and spice-server, and the actual local/remote
> detection code - will ask questions later]
> 
> _______________________________________________
> Spice-devel mailing list
> Spice-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/spice-devel

-- 

David Jaša, RHCE

SPICE QE based in Brno
GPG Key:     22C33E24 
Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3 3E24


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5727 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/spice-devel/attachments/20130624/11cbbefe/attachment-0001.bin>