Bug 1436589

Summary:	RFE: Handle closed connections/channels
Product:	Red Hat Enterprise Linux 8	Reporter:	David Jaša <djasa>
Component:	spice-gtk	Assignee:	Default Assignee for SPICE Bugs <rh-spice-bugs>
Status:	CLOSED WONTFIX	QA Contact:	SPICE QE bug list <spice-qe-bugs>
Severity:	high	Docs Contact:
Priority:	medium
Version:	8.0	CC:	cfergeau, dblechte, fziglio, jjongsma, mtessun, rbalakri, tpelka, victortoso
Target Milestone:	rc	Keywords:	FutureFeature
Target Release:	8.1
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2020-09-01 13:18:47 UTC	Type:	Feature Request
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:	1719736
Bug Blocks:

Description David Jaša 2017-03-28 09:04:22 UTC

Description of problem:
Spice-server handles stale connections for quite some time already: it closes them. On the other hand, spice-gtk doesn't handle them in any way: it either just stops transfering the data for non-main channels, or the whole remote desktop "freezes". This happens frequently with proxies or NATs with agressive timeouts.
Users don't expect such an experience, when e.g. everything appears fine but sound from VM suddenly doesn't reach the client, or conversely, music keeps playing but display goes stale.

Spice-gtk should therefore handle closed connections. The most "expected" way is IMO to reconnect non-main channels and for main channel, either exit (like when VM shuts down) or give some non-intrusive message that connection broke.

Version-Release number of selected component (if applicable):
el7:
  spice-gtk3-0.33-1.el7.x86_64 
  virt-viewer-5.0-2.el7.x86_64
w10:
  VirtViewer v2.0-208
  mingw32-spice-gtk3-0.31-6.el7ev.noarch

How reproducible:
always

Steps to Reproduce:
1. connect to a VM through a network/proxy with short TCP connection timeouts
2.
3.

Actual results:
as various idle channels disconnect, respective parts of client stop working

Expected results:
client reconnects the channels or exits

Additional info:

Comment 1 Christophe Fergeau 2017-03-28 09:55:33 UTC

(In reply to David Jaša from comment #0)
> Actual results:
> as various idle channels disconnect, respective parts of client stop working
> 
> Expected results:
> client reconnects the channels or exits
> 

Alternatively, we could make sure no channels get disconnected if there is activity on one of them. Reconnecting is made a bit harder if a ticket was initially required, I don't know what would happen if we disconnect/reconnect a usbredir channel with an idle USB device redirected, ...

Comment 2 David Jaša 2017-03-28 13:53:44 UTC

(In reply to Christophe Fergeau from comment #1)
> Alternatively, we could make sure no channels get disconnected if there is
> activity on one of them. Reconnecting is made a bit harder if a ticket was
> initially required, I don't know what would happen if we
> disconnect/reconnect a usbredir channel with an idle USB device redirected,
> ...

True.

This bug may also be mitigated by fixing of bug 1428804, if that doesn't turn out (for example, I've experienced disconnections over WAN even when using versions that enable TCP_KEEPALIVE), probably by sending RED_PING after some inactivity period.

Comment 5 Martin Tessun 2019-11-25 08:22:20 UTC

This sounds like a huge usability improvement. Having some feedback on disconnected channels is helpful, so the use knows what is going on. Even in case the user would need to restart his viewer to get the reconnect it is better than having no feedback on what is happening.