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@xxxxxxxxxxxxxxxxxxxxx > 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
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Spice-devel mailing list Spice-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/spice-devel