xpra icon
Bug tracker and wiki

Opened 2 years ago

Closed 2 years ago

#838 closed enhancement (fixed)

html5 client auto-connect

Reported by: Antoine Martin Owned by: Antoine Martin
Priority: minor Milestone: 0.15
Component: html5 Version: trunk
Keywords: Cc:

Description

I think this used to be the case before, not 100% sure.

I would like to be able to do this:

xpra start --bind-tcp=0.0.0.0:10000 --start-child=xterm --html=on

Then just point my browser to it:

firefox http:127.0.0.1:10000

And be able to see the xterm without first going through the connect page.

Attachments (4)

autoconnectlog.txt (24.8 KB) - added by Josh 2 years ago.
log of successful and failed auto connect
chrome-network-debug.png (63.6 KB) - added by Antoine Martin 2 years ago.
chrome's network debug output
proxy-network-debugging.patch (3.2 KB) - added by Antoine Martin 2 years ago.
adds debugging to the low level network code
fix-steal-connection-race.patch (5.1 KB) - added by Antoine Martin 2 years ago.
a possible fix - not pretty

Download all attachments as: .zip

Change History (17)

comment:1 Changed 2 years ago by Josh

The correct behaviour should be as follows:

Load index.html -> auto connect -> if no hello packet received (or socket was closed before hello) redirect to connect.html


If you start Xpra using the following:

xpra start --bind-tcp=0.0.0.0:10000 --tcp-proxy=127.0.0.1:8080
websockify --web ./Xpra/trunk/html5/ 8080 localhost:10000

then it works correctly if you navigate to http://localhost:8080 - it will auto connect every time.

However if you navigate to http://localhost:10000 - sometimes it will auto connect and sometimes it will not.

If you start Xpra using the following:

xpra start --bind-tcp=0.0.0.0:10000 --start-child=xterm --html=on

and then navigate to http://localhost:10000 sometimes it will auto connect and sometimes it will not.


It seems as though if you connect to where websockify listens directly, it works fine. If you connect through Xpra's tcp proxy to websockify it does not work every time.

The client before r9050 shows the same behaviour.

Changed 2 years ago by Josh

Attachment: autoconnectlog.txt added

log of successful and failed auto connect

comment:2 Changed 2 years ago by Antoine Martin

Owner: changed from Josh to Antoine Martin
Status: newassigned

Hah, ok. Then it's probably a bug on my side then.
Taking the ticket back.

Changed 2 years ago by Antoine Martin

Attachment: chrome-network-debug.png added

chrome's network debug output

comment:3 Changed 2 years ago by Antoine Martin

Owner: changed from Antoine Martin to Josh
Status: assignednew

Not sure what is going on here - it works, sometimes. Sometimes not:

2015-04-21 01:13:41,574 New connection received: SocketConnection(('127.0.0.1', 10000) - ('127.0.0.1', 54898))
2015-04-21 01:13:41,575 New connection received: SocketConnection(('127.0.0.1', 10000) - ('127.0.0.1', 54899))
2015-04-21 01:13:41,575 New connection received: SocketConnection(('127.0.0.1', 10000) - ('127.0.0.1', 54900))
2015-04-21 01:13:41,576 New connection received: SocketConnection(('127.0.0.1', 10000) - ('127.0.0.1', 54901))
2015-04-21 01:13:41,576 New connection received: SocketConnection(('127.0.0.1', 10000) - ('127.0.0.1', 54902))
2015-04-21 01:13:41,576 New connection received: SocketConnection(('127.0.0.1', 10000) - ('127.0.0.1', 54903))
2015-04-21 01:13:41,579 client SocketConnection(('127.0.0.1', 10000) - ('127.0.0.1', 54898)) forwarded to proxy server 127.0.0.1:49657
2015-04-21 01:13:41,594 Connection lost
2015-04-21 01:13:41,594 xpra client disconnected.
2015-04-21 01:13:41,665 New connection received: SocketConnection(('127.0.0.1', 10000) - ('127.0.0.1', 54905))
2015-04-21 01:13:41,666 client SocketConnection(('127.0.0.1', 10000) - ('127.0.0.1', 54905)) forwarded to proxy server 127.0.0.1:49657
 32: 127.0.0.1: Plain non-SSL (ws://) WebSocket connection
 32: 127.0.0.1: Version hybi-13, base64: 'False'
 32: connecting to: 127.0.0.1:10000
2015-04-21 01:13:41,668 New connection received: SocketConnection(('127.0.0.1', 10000) - ('127.0.0.1', 54907))
2015-04-21 01:13:43,646 Connection lost
2015-04-21 01:13:51,576 connection timedout: Protocol(SocketConnection(('127.0.0.1', 10000) - ('127.0.0.1', 54899)))
2015-04-21 01:13:51,576 connection timedout: Protocol(SocketConnection(('127.0.0.1', 10000) - ('127.0.0.1', 54900)))
2015-04-21 01:13:51,577 connection timedout: Protocol(SocketConnection(('127.0.0.1', 10000) - ('127.0.0.1', 54901)))
2015-04-21 01:13:51,577 connection timedout: Protocol(SocketConnection(('127.0.0.1', 10000) - ('127.0.0.1', 54902)))
2015-04-21 01:13:51,577 connection timedout: Protocol(SocketConnection(('127.0.0.1', 10000) - ('127.0.0.1', 54903)))

All those connections are made by the browser to fetch different page assets (javascript includes, etc).
The firebug-like chrome debugger shows that inflate.min.js is missing. Odd:
chrome's network debug output

r9088 makes it easier to debug proxy + network issues, with this I can see lots of:

untilConcludes(<bound method SocketConnection.is_active of SocketConnection(('127.0.0.1', 10000) - ('127.0.0.1', 54929))>, <built-in method recv of _socket.socket object at 0x44ec810>, (65536,), {}) timed out

Maybe we need to reset the sockets to blocking mode instead of timing out? (it should still work though...)

@joshiggins: any thoughts?

comment:4 Changed 2 years ago by Josh

The inflate.min.js is minified and chrome is requesting a source map inflate.min.js.map to show the original code in the debugger, but it's not there. Doesn't seem to request it unless you open the debugger tools. So that one is expected.

I'm not sure what to make of the rest.

2015-04-21 01:13:51,577 connection timedout: Protocol(SocketConnection(('127.0.0.1', 10000) - ('127.0.0.1', 54903)))

I assume that for these, Xpra was waiting for a client handshake but they probably should have gone to websockify?

comment:5 Changed 2 years ago by Antoine Martin

Minor fixes that could help in r9104 + r9105.
r9096 makes debugging the proxy stuff a little easier.

I am still seeing failures in about 50% of the time.
@joshiggins: how do I enable debugging of the html5 code to see where it is at? (especially the page loading, startup / connect code)

comment:6 Changed 2 years ago by Josh

@antoine, with r9106 you can add index.html?debug=true to avoid the connect page redirect. The web console should show the usual messages.

It will say received an 'open' packet when the websocket is opened.

comment:7 Changed 2 years ago by Antoine Martin

Owner: changed from Josh to Antoine Martin
Status: newassigned

@joshiggins: thanks, that's very useful.

It seems that whenever it fails, it gets stuck after sending the hello. At least now I know where to look.

comment:8 Changed 2 years ago by Antoine Martin

Not had time to look into it, but with the latest trunk I get:

disconnect: invalid packet format, not an xpra client?

Is it just me?

comment:9 Changed 2 years ago by Josh

Not seeing this on my end with latest trunk.....

comment:10 Changed 2 years ago by Antoine Martin

Not seeing this on my end with latest trunk.....


Never mind, that was me getting it completely wrong and hitting the wrong server!


Inspecting the packets over the "wire", I can see that when things fail, they fail just after the request to "switch protocols" from the websockify server:

T 127.0.0.1:36534 -> 127.0.0.1:49087 [AP]
  HTTP/1.1 101 Switching Protocols..Upgrade: websocket..Connection: Upgrade..Sec-WebSocket-Accept: 63KVuzlVx/3Lj54jOsM1X6ef+hk=..Sec-WebSocket-Protocol: 
  binary....

Which we correctly forward to the client.

The client then responds with some binary data, which we forward to the websockify server... except when the bug occurs: it looks like the data is sent to the xpra server, but never received or forwarded to the websockify server.

Changed 2 years ago by Antoine Martin

adds debugging to the low level network code

Changed 2 years ago by Antoine Martin

a possible fix - not pretty

comment:11 Changed 2 years ago by Antoine Martin

The bug has been identified and also affects the proxy server (#426).

The fix above is probably correct, I just wished it wasn't so convoluted - tying the steal_connection code with connection.set_active and things that should be hidden away..

comment:12 Changed 2 years ago by Antoine Martin

Finally fixed in r9160!

I think that the proxy server code is safe because we do not expect any packets after the hello until we have replied with our own hello response.
This is a bit big to backport, will need to think about it.

comment:13 Changed 2 years ago by Antoine Martin

Resolution: fixed
Status: assignedclosed

Backport in r9173. (not all that big, tested ok)

Note: See TracTickets for help on using tickets.