xpra icon
Bug tracker and wiki

Opened 2 months ago

Last modified 9 days ago

#1581 assigned task

html5 2.2 updates

Reported by: Antoine Martin Owned by: Antoine Martin
Priority: major Milestone: 2.2
Component: html5 Version: trunk
Keywords: Cc:

Description (last modified by Antoine Martin)

Follow up from #1491 (for 2.1).

Now also on github where pull requests can be submitted: https://github.com/totaam/xpra-html5/

Change History (3)

comment:1 Changed 5 weeks ago by Antoine Martin

Status: newassigned

As part of the network layer work (#1590), it would be very useful to hook into the Network Information API to have some information about the type of connection the browser is using, what latency can be expected, get notified about (dis)connection events, etc
This information could be provided to the server as hints it can feed into its own heuristics.

comment:2 Changed 3 weeks ago by Antoine Martin

Description: modified (diff)

comment:3 Changed 9 days ago by Antoine Martin

As of r16824, we expose this information to the server as "connection-data" for each client that provides it.

The big problem is that this connection API looks buggy as hell, at least the downlink value is.
Here is some data with a Fedora 26 server, chrome 62 Fedora 26 client, the "download" value is nowhere near the system settings (values are in bits per second):

  • 100 Mbps interface: 'rtt': 100, 'downlink': 100000, 'effective-type': '4g', 1000 times less!
  • same interface but reconfigured as half-duplex 10Mbps with ethtool -s eth0 speed 10 duplex half : 'rtt': 300, 'downlink': 1350000, 'effective-type': '3g', closer only ~6 times lower... (same values with full duplex)
  • after re-configuring it to 100 Mbps.. now same as 10 Mbps...
  • loopback interface: 'rtt': 100, 'effective-type': '4g'
  • chrome 61 on win32 connecting via a paravirtualized network driver (1000Mbps?): 'rtt': 100, 'downlink': 1450000, 'effective-type': '4g'
  • Windows 7 server, Linux client over paravirtualized network driver: 'rtt': 100, 'effective-type': '4g'
  • Windows 7 server, local client: 'rtt': 75, 'downlink': 1450000, 'effective-type': '4g'

Firefox 55 and Safari 10.1.2 have no support for this API yet.

So, if anything the "effective-type" is more reliable than the "downlink" value.
And I've tried turning on and off my network interfaces, the "onchange" event handler never fired... so we can't use that to detect when the network connection drops.

Last edited 9 days ago by Antoine Martin (previous) (diff)
Note: See TracTickets for help on using tickets.