move websockify in the xpra process

[Antoine Martin]

So we don't have to exec anything, then we also won't be needing the proxy instance running xpra side (which is forwarding to and from the websockify process, using 2 threads).
See also #1134.

[Antoine Martin]

move websockify handling in process

[Antoine Martin]

The patch above works fine, only left todo:

• handle html=/path/to/www and generate / detect correct path (ie: on osx, in the app bundle)
• TLS setup
• man page updates
• test tcp-proxy mode better
• use the peek function to avoid creating a whole protocol instance (and threads) if the packet header is invalid
• verify blocking sockets and timeout values

[Antoine Martin]

Mostly done in r12688. Firefox is still having problems, but that doesn't seem to be anything new.
Still todo:

• TLS
• bail out early on invalid packet header

[Antoine Martin]

attempts at preventing ssl from deadlocking - failed

[Antoine Martin]

• r12708 fixes an error with win32 servers (but win32 servers still don't support the html5 client: #1211)
• r12699 bails out early
• I give up on SSL for now - will follow up in #1213, the patch above tries to use a thread as early as possible, setting timeouts on the sockets, raising the number of sockets we create, etc.. to no avail

---

@afarr: the html client should be faster now

[J. Max Mena]

HTML client is by far faster. It's like night and day faster now.

I'd say performance in Chrome is 90% as good as Python.

[J. Max Mena]

Oh, sorry, I hit submit without thinking.

Closing.

[Antoine Martin]

Milestone renamed

[migration script]

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