xpra icon
Bug tracker and wiki

Opened 5 months ago

Closed 4 months ago

#1559 closed defect (needinfo)

Websocket proxing

Reported by: oleg.z Owned by: oleg.z
Priority: major Milestone: 2.1
Component: network Version: trunk
Keywords: Cc:

Description

Dear XPRA team,

We have a setup, where we deployed multiple XPRA servers, which are running on localhost. At the same time, we developed Websocket proxy, which allows users to connect using html client.

Our problem is that after some time, we get an error message "server connection is not responding, drawing spinners" on the client side.

The data flow described in the following:

HTML client <--> Java Websocket Proxy <--> Java Websocket Client Simulator <--> Xpra Server

We suppose that Client simulator transmits a way more packages, than client is able to handle.

This issue does not apper, if we run something simple (basic Windows or Amiga emulators). However it is a big problem, in case of GPU depending applications like Graveyard http://tale-of-tales.com/TheGraveyard/. We are using multiple Xdummy servers and virtualGl.

What would be your tips for our usecase?

Sincerely,
Oleg

Change History (3)

comment:1 Changed 5 months ago by Antoine Martin

Component: androidnetwork
Milestone: 2.1
Owner: changed from Antoine Martin to oleg.z

We suppose that Client simulator transmits a way more packages, than client is able to handle.

I assume that you mean that the server sends too many packets?

Does the problem go away if you go straight through without using your proxy? (why do you need it?)
What is the "Java Websocket Client Simulator" and what does it do?
Can you reproduce the problem by running the python client with a websocket connection? Using a websocket URI, ie:

xpra attach ws/HOST:PORT/

The type of application used shouldn't matter much, only the amount of pixels that need to be transferred. Can you reproduce with a test application like "glxgears" or "glxspheres"?

comment:2 in reply to:  1 Changed 5 months ago by oleg.z

Replying to Antoine Martin:

We suppose that Client simulator transmits a way more packages, than client is able to handle.

I assume that you mean that the server sends too many packets?

Yes, XPRA server sends us packets faster, than we are able to forward

Does the problem go away if you go straight through without using your proxy? (why do you need it?)

Yes. We do not face this problem, if we go straight to the endpoint without using proxy.
We developed it, in order to have multiple xpra sessions on one port and to retrieve sessions ourselves without client interference. So, from the client side, xpra window appears just by a single click.

What is the "Java Websocket Client Simulator" and what does it do?

It forwards packets from our Proxy to the Xpra Server and vica versa (we mentioned it, because it might cause a mess with ping messages).

Can you reproduce the problem by running the python client with a websocket connection? Using a websocket URI, ie:

xpra attach ws/HOST:PORT/

Our framework uses links with the following pattern: "{host}:{port}/{other components}/{id}/xpra/". It seems that python client does not support this format. It considers "/{other components}/{id}/xpra/" as a display number.

The type of application used shouldn't matter much, only the amount of pixels that need to be transferred. Can you reproduce with a test application like "glxgears" or "glxspheres"?

We can reproduce the same issue, if we run it with high resolution. Glxgears with regular resolution works more or less fine. We still can see the spinner, but it disappears after a short time.

comment:3 Changed 4 months ago by Antoine Martin

Resolution: needinfo
Status: newclosed
Note: See TracTickets for help on using tickets.