On 03/12/12 19:45, Yonit Halperin wrote:
Hi,
On 03/12/2012 03:50 PM, Gerd Hoffmann wrote:
Hi,
Can you explain/exemplify, why sending data as a blob (either by (a) or
(b)), that is verified only by the two ends that actually use it, is a
problem?
It tends to be not very robust.
Hi,
On 03/13/2012 08:40 AM, Gerd Hoffmann wrote:
On 03/12/12 19:45, Yonit Halperin wrote:
Hi,
On 03/12/2012 03:50 PM, Gerd Hoffmann wrote:
Hi,
Can you explain/exemplify, why sending data as a blob (either by (a) or
(b)), that is verified only by the two ends that actually use it, is a
Hi,
It is not easy when you have 2 components, and it is much less easy when
you have 3 or 4 components. So why make it more complicated if you can
avoid it. Especially since there is no functional reason for making the
qemu/client capabilities/versions dependent on the server internal
Hi,
On 03/11/2012 02:16 PM, Yonit Halperin wrote:
Hi,
We would like to implement seamless migration for Spice, i.e., keeping the
currently opened spice client session valid after migration.
Today, the spice client establishes the connection to the destination before
migration starts, and
Hi,
On 03/12/2012 08:57 AM, Gerd Hoffmann wrote:
Hi,
What about the second part? it's independant of the async issue.
Isn't this a client problem? The client has this state, no?
It is state of the client- server session. Today spice client
creates a new session on migration, so
Hi,
The problem with (b) is, that iirc the way b was implemented in the past
was still the big blob approach, but then pass the blob through the client,
which means an evil client could modify it, causing all sorts of
interesting
behavior inside spice-server. Since we're re-implementing
On Mon, Mar 12, 2012 at 10:46:44AM +0100, Gerd Hoffmann wrote:
Hi,
The problem with (b) is, that iirc the way b was implemented in the past
was still the big blob approach, but then pass the blob through the client,
which means an evil client could modify it, causing all sorts of
Hi,
As for certain other
data, such
as (but not limited to) partially parsed agent messages, these should be
send through the regular vmstate methods IMHO.
That isn't easy to handle via vmstate, at least as soon as this goes
beyond a fixed number of fields aka 'migrate over this struct
Hi,
On 03/12/2012 10:46 AM, Gerd Hoffmann wrote:
Hi,
The problem with (b) is, that iirc the way b was implemented in the past
was still the big blob approach, but then pass the blob through the client,
which means an evil client could modify it, causing all sorts of
interesting
behavior
On Mon, Mar 12, 2012 at 11:26:50AM +0100, Gerd Hoffmann wrote:
Hi,
As for certain other
data, such
as (but not limited to) partially parsed agent messages, these should be
send through the regular vmstate methods IMHO.
That isn't easy to handle via vmstate, at least as soon as
On 03/12/12 12:29, Alon Levy wrote:
On Mon, Mar 12, 2012 at 11:26:50AM +0100, Gerd Hoffmann wrote:
Hi,
Migrate this struct n times for me.
I think for the agent case this isn't needed. Or is every client
allowed to speak to the agent in case of multiple clients connected? I
somehow
Hi,
Is there a complete list of the session state we need to save?
There is still code in spice-server for the old seamless migration,
someone could go through that and use that as an initial list of
session state we need to save.
That doesn't help much as it is _way_ too old. Predates
On Mon, Mar 12, 2012 at 12:34:42PM +0100, Gerd Hoffmann wrote:
On 03/12/12 12:29, Alon Levy wrote:
On Mon, Mar 12, 2012 at 11:26:50AM +0100, Gerd Hoffmann wrote:
Hi,
Migrate this struct n times for me.
I think for the agent case this isn't needed. Or is every client
allowed to
Hans de Goede píše v Po 12. 03. 2012 v 09:51 +0100:
Hi,
On 03/12/2012 08:57 AM, Gerd Hoffmann wrote:
Hi,
What about the second part? it's independant of the async issue.
Isn't this a client problem? The client has this state, no?
It is state of the client- server session.
On 03/12/2012 11:46 AM, Gerd Hoffmann wrote:
Hi,
The problem with (b) is, that iirc the way b was implemented in the past
was still the big blob approach, but then pass the blob through the client,
which means an evil client could modify it, causing all sorts of
interesting
behavior inside
On 03/12/12 12:45, Alon Levy wrote:
On Mon, Mar 12, 2012 at 12:34:42PM +0100, Gerd Hoffmann wrote:
On 03/12/12 12:29, Alon Levy wrote:
Actually the agent protocol does extend nicely to multiple clients - I
forgot the name but there is an additional wrapper between the
client/server
On Mon, Mar 12, 2012 at 01:44:47PM +0100, Gerd Hoffmann wrote:
On 03/12/12 12:45, Alon Levy wrote:
On Mon, Mar 12, 2012 at 12:34:42PM +0100, Gerd Hoffmann wrote:
On 03/12/12 12:29, Alon Levy wrote:
Actually the agent protocol does extend nicely to multiple clients - I
forgot the name
Hi,
Can you explain/exemplify, why sending data as a blob (either by (a) or
(b)), that is verified only by the two ends that actually use it, is a
problem?
It tends to be not very robust. Especially when the creating/parsing is
done ad-hoc and the format changes now and then due to more
On Mon, Mar 12, 2012 at 04:24:16PM +0200, Alon Levy wrote:
On Mon, Mar 12, 2012 at 01:44:47PM +0100, Gerd Hoffmann wrote:
On 03/12/12 12:45, Alon Levy wrote:
On Mon, Mar 12, 2012 at 12:34:42PM +0100, Gerd Hoffmann wrote:
On 03/12/12 12:29, Alon Levy wrote:
Actually the agent
Hi,
On 03/12/2012 03:50 PM, Gerd Hoffmann wrote:
Hi,
Can you explain/exemplify, why sending data as a blob (either by (a) or
(b)), that is verified only by the two ends that actually use it, is a
problem?
It tends to be not very robust. Especially when the creating/parsing is
done ad-hoc
20 matches
Mail list logo
