Xpra: Ticket #1271: support websockets in the python client

We already support websockets as transport in the server, see #1136 / #1134, so we could support websockets in the python client as well. (we already have ssh, ssl, tcp and unix / named-pipes!)

I don't see the point of adding this one: we try hard to avoid copying data in the network layer and using websockets will cause more of it, using more CPU.



Sun, 04 Sep 2016 04:53:18 GMT - Antoine Martin: status changed

Found: https://github.com/liris/websocket-client which supports python 2. This may help with things like #1298.


Sun, 04 Sep 2016 06:03:18 GMT - Antoine Martin: milestone changed

Implemented basic support in r13558, hoping this will help debug #1298. You can now connect using a websocket transport:

xpra attach ws/127.0.0.1:10000/

Looking at the traffic, it's not pretty: redundant size headers, etc... #1134 may help a bit here, but ultimately this transport is very unlikely to ever perform as well as the plain xpra protocol it wraps.

Still TODO:


Mon, 05 Sep 2016 04:52:54 GMT - Antoine Martin:

Minor updates:


Wed, 07 Sep 2016 04:16:48 GMT - Antoine Martin: owner, status changed

(successfully establishes the SSL connection to the server but then fails because of the issue in ticket:1213#comment:3)


Excluding the wss issue above, this is ready for testing. See also #1213 @afarr: you should be able to use ws URL connection strings with the latest clients. This is useful for testing the same transport layer used by the html5 client.


Thu, 08 Jun 2017 22:43:13 GMT - alas: status changed; resolution set

Interesting. Tested the permutations with 1.0.6 r15627 osx client (10.12) against a 1.0.7 r16032 fedora 25 server.

Each permutation worked without so much as a wrinkle. Good to know the clients will work over the same transport layer.

Closing.


Wed, 20 Feb 2019 05:25:24 GMT - Antoine Martin:

See also #2121


Sat, 23 Jan 2021 05:19:41 GMT - migration script:

this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/1271