Xpra: Ticket #1964: proxy receives connection-lost

  1. Started up a VM and ran xpra server on Ubuntu 18.04 compute node:
xpra start-desktop :200 --bind-tcp=0.0.0.0:10100 --start=startxfce4 --start-via-proxy=no --video-encoders=none -d compress --no-printing --rfb-upgrade=0
  1. Started proxy server on separate Ubuntu 18.04 machine with K10 NVIDIA GPUs installed:
xpra proxy :100 --bind-tcp=0.0.0.0:14501 --tcp-auth=sqlite,filename=./xpra-auth.sdb --socket-dir=/tmp --dbus-launch=no --dbus-control=no  --video-encoders=nvenc -d encoding,proxy

[valid user created in xpra-auth.sdb, confirmed as working]

  1. On a 3rd (Windows) machine connected to server through proxy using the following xpra attach command in a cmd window:
xpra_cmd.exe attach tcp/uname:pword@proxy_ip:14501 --encodings=webp,jpeg,h264,vp8,vp9,png,rgb

This opened up an Xfwm4 window which displayed my xfce4 desktop which I seem to be able to use.

(Performance appears average and laggy. When I click on the Xpra icon in the system tray, H264 is greyed out under Encodings.)

  1. Clicked on the Xpra icon in the system tray and disconnected Xpra.
  1. Opened chrome and entered http://proxy_ip:14501/connect.html in the address bar. Xpra attempts to connect but fails with "Did not receive hello before timeout reached, not an Xpra server?".

Javascript console log and proxy log attached.



Wed, 19 Sep 2018 11:32:19 GMT - danh1978: attachment set

proxy log extract


Wed, 19 Sep 2018 11:32:44 GMT - danh1978: attachment set

javascript console extract


Wed, 19 Sep 2018 12:30:50 GMT - Antoine Martin: priority, status, component, description changed; milestone set

This should work, maybe a websocket problem in the proxy.


Sat, 22 Sep 2018 16:49:03 GMT - Antoine Martin: owner, status changed

For the record, because of a bug (fix in r20454) with NVENC wrongly trying to use encodings that are known not to work, I advised danh1978 to specify --encodings=webp,jpeg,h264,vp8,vp9,png,rgb. This is probably not related to the HTML5 client connection failure.

Performance appears average and laggy.

Desktop servers are never going to feel as fast as seamless servers, mainly because the windows are managed server side instead of client side. The proxy also introduces a little bit of latency. It could also do with a bit more optimization. (better queue management, etc)

That said, when I tried it things were quite usable.

When I click on the Xpra icon in the system tray, H264 is greyed out under Encodings

That's odd. Please post the "xpra info" output for both the server and the proxy. Maybe you're not using NVENC then.

Xpra attempts to connect but fails with "Did not receive hello before timeout reached, not an Xpra server?".

Works fine here. (Fedora 28) Are you sure that you're specifying the correct port, username, etc? Have you tried using the HTML5 client directly on the server? Try enabling all the debug switches on the HTML5 advanced connection form, and post the new javascript console output.

Maybe you can try the latest beta builds and see if they work any better for you: https://xpra.org/beta.


Wed, 26 Sep 2018 10:02:23 GMT - danh1978:

Hi Antoine

I decided to try a simpler approach using Fedora 28 and try to get a proof of concept up and running without the proxy server encoding.

I appreciate all your help. I'm happy for you to close this ticket.


Wed, 26 Sep 2018 12:01:20 GMT - Antoine Martin: status changed; resolution set


Sat, 23 Jan 2021 05:38:30 GMT - migration script:

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