[winswitch] Random connection drops in browser client

[Michael Cronenworth]

On 11/30/20 11:29 PM, Antoine Martin via shifter-users wrote:
> Does this also occur if you connect a regular python client to the same
> session?

I have not tried it yet, so I installed the 4.0.5 Windows client. After a few 
minutes the thick client also disconnects. In this instance I was using Firefox and 
randomly left and right clicking on the redhat.com web page and eventually it 
disconnected the client. The server log shows similar messages as the HTML5 client.

> Can you try to run your server with --debug=network and post the last
> few messages just before the client disconnection message?

HTML 5 client (wss connection):
With network debugging enabled I am seeing the client request a disconnect. Then the 
server times out on the reconnect and a second reconnect establishes.

...
2020-12-08 07:37:35,978 process ui packet pointer-position
2020-12-08 07:37:35,978 processing packet pointer-position
2020-12-08 07:37:35,978 process ui packet pointer-position
2020-12-08 07:37:36,004 packet type send alias not found for 'draw'
2020-12-08 07:37:36,007 processing packet disconnect
2020-12-08 07:37:36,007 process default packet disconnect
2020-12-08 07:37:36,007 client has requested disconnection: server shutdown (client 
connection lost)
... tries to reconnect, but I see a timeout
2012-12-08 07:37:39,339 peek: elapsed=751, timeout=1000
2012-12-08 07:37:39,559 peek: elapsed=1001, timeout=1000
2012-12-08 07:37:39,559 socket unix-domain 
socket:/run/user/<redacted>/xpra/<hostname>-0 peek: got 0 bytes
...
2012-12-08 07:37:39,565 process_connection_list(Protocol(None), ['connection-lost'])
2012-12-08 07:37:39,565 cleanup_protocol(Protocol(None))
2012-12-08 07:37:39,589 peek: elapsed=1001, timeout=1000
... tries to reconnect, and succeeds

Python client (wss connection):
The logs say the client requested a disconnect. The client doesn't auto-reconnect 
like the HTML5 client does so the log ends.

...
2020-12-08 08:45:21,060 processing packet pointer-position
2020-12-08 08:45:21,060 process ui packet pointer-position
2020-12-08 08:45:21,068 processing packet pointer-position
2020-12-08 08:45:21,068 process ui packet pointer-position
2020-12-08 08:45:21,085 processing packet disconnect
2020-12-08 08:45:21,085 processing default packet disconnect
2020-12-08 08:45:21,085 client has requested disconnection: server shutdown (client 
connection lost)
...

> That's quite odd. The "websocket closed" event can only come from 3 places:
> * the server sending a "close" message (which would include a reason)
> * a protocol error in the HTML5 client (also includes a message)
> * the browser tears it down unceremoniously
>
> Only the last one would not include a "reason" message.
> Applying this patch will now include more details:
> http://xpra.org/trac/changeset/28048/xpra
> You can either apply it by hand or use the copy found here:
> http://xpra.org/html5/connect.html
>
> Other things worth trying:
> * use a tunnel to ensure that the websocket traffic isn't modified
> * use wireshark to inspect the last few packets before the connection
> drops (you should be able to see which end is closing first)
>

I have not tried this patch yet, or a packet capture, but I will if you think it is 
worth pursuing.

Thank you,
Michael