support websockets in the python client

[totaam]

Issue migrated from trac ticket # 1271

component: client | priority: minor | resolution: fixed

2016-08-01 06:10:16: antoine created the issue

---

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.

[totaam]

2016-09-04 05:53:19: antoine changed status from new to assigned

[totaam]

2016-09-04 05:53:19: antoine commented

---

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

[totaam]

2016-09-04 07:03:19: antoine commented

---

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:

• man page updates (maybe revamp the whole display connection string to avoid copying the same information everywhere)
• support parameters on the URL
• maybe expose the underlying TCP socket's details via get_info
• hook ssl options

[totaam]

2016-09-05 05:52:54: antoine commented

---

Minor updates:

• r13559: added to osx moduleset
• r13560: connection closed handling, extra socket info
• r13562: we can now use this connection string syntax: ws[s]/username:password@host:port/path?arg=val&etc

[totaam]

2016-09-07 05:16:49: antoine changed status from assigned to new

[totaam]

2016-09-07 05:16:49: antoine changed owner from antoine to afarr

[totaam]

2016-09-07 05:16:49: antoine commented

---

• r13594: man page updates
• r13596 seems to allow us to use SSL connections (blocked by http / websockify ssl support #1213), ie with a server configured with a self-signed CA as per [r13596](.. commit a01c993) seems to allow us to use SSL connections (blocked by ](r13596](..-commit-a01c9934d451596c4ffac3a6d49c416ae6233e85) seems to allow us to use SSL connections (blocked by ):

xpra attach wss:127.0.0.1:10000 --ssl-ca-cert=./ca.crt

(successfully establishes the SSL connection to the server but then fails because of the issue in #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.

[totaam]

2017-06-08 23:43:13: afarr changed status from new to closed

[totaam]

2017-06-08 23:43:13: afarr set resolution to fixed

[totaam]

2017-06-08 23:43:13: afarr commented

---

Interesting.
Tested the permutations with 1.0.6 15627 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.

[totaam]

2019-02-20 05:25:24: antoine commented

---

See also #2121