Migration can occur between 2 spice-servers with different mm-times.
Then, the following cases can happen after migration completes:
(I refer to src/dst-time as the mm-times on the src/dst servers):
(case 1) Frames with time ~= dst-time arrive to the client before the
playback-channel updates the session's mm-time (i.e., the mm_time
of the session is still based on the src-time).
(a) If src-time < dst-time:
display_stream_schedule schedules the next rendering to
~(dst-time - src-time) milliseconds from now.
Since we assume monotonic mm_time, display_stream_schedule,
returns immediately when a rendering timeout
has already been set, and doesn't update the timeout,
even after the mm_time is updated.
When src-time << dst-time, a significant video frames loss will occur.
(b) If src-time > dst-time
Frames will be dropped till the mm-time will be updated.
(case 2) mm-time is synced with dst-time, but frames that were in the command
ring during migration still arrive (such frames hold src-time).
(a) If src-time < dst-time
The frames that hold src-time will be dropped, since their
mm_time < session-mm_time. But all the new frames that are generated in
the driver after migration, will be rendered appropriately.
(b) If src-time > dst-time
Similar consequences as in 1 (a)
case 2 is less likely, since it takes at least 20 frames till the dst-server re-identifies
the video stream and starts sending stream data
This race scenario is unique to migration. When a *new* client connection is established with a server,
the main channel INIT msg, contains the mm_time. All the data transfer in the other channels is started
only after the client's main channel received the INIT msg. In migration however, in order to avoid
additional delays, all the channels are connected independently.
The proposed patch for spice-gtk tests for case 1.a and case 2.b and handles them.
Other possible solutions I have in mind involves both spice-gtk and spice-server:
(1) (a) Change the migraion handshake between the client and the dest-server
(occurs before migration starts) to also include the dst mm-time.
This way, the client's session mm-time will be valid after migration.
(solves case 1.a)
(b) The dst-server should drop frames with mm-time > dst-mm-time (solves case 2.b)
(2)
(a) spice-gtk won't render video after migration, till the session-mm-time
is reset (solves case 1.a)
(b) The dst-server should drop frames with mm-time > dst-mm-time (solves case 2.b)
Obviously, these options require that both spice-gtk and spice-client will be new (
though (2) doesn't require protocol changes).
For video streams without audio, I will also send a patch that sends SPICE_MSG_MAIN_MULTI_MEDIA_TIME after migration
(unless solution (1) above is chosen).
Comments?
Yonit.
Yonit Halperin (1):
channel-display: protect video streaming from temporally unsynced
mm_time (migration related)
gtk/channel-display.c | 104 ++++++++++++++++++++++++++++++++++++++++++++++++--
1 file changed, 101 insertions(+), 3 deletions(-)
--
1.8.1.4
_______________________________________________
Spice-devel mailing list
Spice-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/spice-devel