diff options
| author | kelvinp@chromium.org <kelvinp@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98> | 2014-05-01 00:19:05 +0000 |
|---|---|---|
| committer | kelvinp@chromium.org <kelvinp@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98> | 2014-05-01 00:19:05 +0000 |
| commit | 324868c2a6c1a8722a490630988a2b00374801b6 (patch) | |
| tree | e7f8137869f9c96c96bdcc35f2f59db3f945c4ab /remoting/remoting_test.gypi | |
| parent | f573168c8c5647c87a5b5620d78d09ef0df9b925 (diff) | |
| download | chromium_src-324868c2a6c1a8722a490630988a2b00374801b6.zip chromium_src-324868c2a6c1a8722a490630988a2b00374801b6.tar.gz chromium_src-324868c2a6c1a8722a490630988a2b00374801b6.tar.bz2 | |
Smart reconnect part II - plugin and host
This CL serves to make the experience below better
“I typically have to manually reconnect 20-40 times per day when working remotely, about 10 reconnects are due to wifi zone changes, and 20 are due to closing my laptop screen (Chromebook Pixel). “ - A customer
Cause:
1. The current implementation of connectivity is not very reliable. It typically takes 5 seconds for us to grey out the app when there is no network connectivity. The app feels irresponsive to network connectivity
There are three factors that causes the connection to drop
2. When the client is suspended, the host times out in 1 min. This is particular common when the user closes the lid of the laptop and walk to another room for meeting. (P1)
3. When the client is not suspended, but cannot reach the host (network changes, host_is_offline)
a. If the timeout is less than 1 min, it will try to reconnect, however, the reconnect could takes up to 2 min. Most people won't have that kind of patience to wait for the reconnect. (P2)
b. If the timeout is larger than 1 min, it will timeout.
Fix:
1. To Fix (1) In a healthy connection, the host send video frames to the client periodically. We can improve the reliability of connection detection to within 1s by checking whether we have received any frames within the last second.
2. To Fix (1) and (2b), we listens for the change in connection state of the session, if it transits from CONNECTED to FAILED and the host is not offline, we reconnect. In order for this to work smoothly, this change increases the timeout of session initiation and session accept.
3. To Fix (3a), when we detect the network connectivity is up again. We will let the transport layer to re-negotiate the transport channels. However, if it doesn't finishes its job within 5 second, the plugin to transit to FAILED state so that the webapp can reconnect
4. I have written an unittest for the video_channel_monitoring code and tested out the app on the chromebook pixel. The experience definitely feels better.
BUG=264300
Review URL: https://codereview.chromium.org/243483004
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@267384 0039d316-1c4b-4281-b951-d872f2087c98
Diffstat (limited to 'remoting/remoting_test.gypi')
| -rw-r--r-- | remoting/remoting_test.gypi | 1 |
1 files changed, 1 insertions, 0 deletions
diff --git a/remoting/remoting_test.gypi b/remoting/remoting_test.gypi index 7be4640..65160c3 100644 --- a/remoting/remoting_test.gypi +++ b/remoting/remoting_test.gypi @@ -142,6 +142,7 @@ 'protocol/jingle_session_unittest.cc', 'protocol/message_decoder_unittest.cc', 'protocol/message_reader_unittest.cc', + 'protocol/monitored_video_stub_unittest.cc', 'protocol/mouse_input_filter_unittest.cc', 'protocol/negotiating_authenticator_unittest.cc', 'protocol/pairing_registry_unittest.cc', |