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
_______________________________________________
shifter-users mailing list
shifter-users@lists.devloop.org.uk
https://lists.devloop.org.uk/mailman/listinfo/shifter-users
