Hello.
We are starting to implement Xpra to provide a remote desktop for our users. The connection between the Xpra client and the Xpra server goes through 2 other servers running a Node application with https://github.com/theturtle32/WebSocket-Node/blob/master/docs/WebSocketServer.md#server-config-options/WebSocket-Node for the authentication.
With these setup we have connection reset and can't find where the problem is.
The log on the server is:
2019-03-13 11:01:09,236 client startup complete
2019-03-13 11:01:09,237 client connection-established
2019-03-13 11:01:09,383 read() got 1 ws frames
2019-03-13 11:01:09,416 read() got 1 ws frames
2019-03-13 11:01:09,747 read() got 1 ws frames
2019-03-13 11:01:09,975 read() closed_string: {'reason': <memory at 0x7fffe411b3e0>, 'code': 1009}
2019-03-13 11:01:09,976 read() got 0 ws frames
2019-03-13 11:01:10,005 xpra client 57 disconnected.
We also got these message on the WSproxy:
SOCKET CLOSED====== 1009 Frame size of 1824283 bytes exceeds maximum accepted frame size
This happen with 2.4.x (latest commit), 2.4.x-r21383 (before the websocket rewrite #2121) and trunk-r22056
I can't find what can cause these error. Any pointer on what to check ?
As per rfc6455 section-5.2: the payload size is only "limited" to 2^63 bytes and your proxy is rejecting our large packets.
You should configure it to allow bigger frames: Server Config Options: see maxReceivedFrameSize and maxReceivedMessageSize. There is no limit in xpra - a reasonable value is 32MB for 4K content. (though typically frames will be smaller than 1MB)
You may have to experiment with fragmentation to get the best latency..
More information here: WebSockets is a stream, not a message based protocol...
FYI: using multiple proxies will also increase latency, which causes other problems.
PS: r22076 will show the actual reason message.
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/2210