1 files changed, 61 insertions, 0 deletions
diff --git a/results/scraper/launchpad-without-comments/1725707 b/results/scraper/launchpad-without-comments/1725707
new file mode 100644
index 000000000..50f0dd4c2
--- /dev/null
+++ b/results/scraper/launchpad-without-comments/1725707
@@ -0,0 +1,61 @@
+QEMU sends excess VNC data to websockify even when network is poor
+
+Description of problem
+-------------------------
+In my latest topic, I reported a bug relate to QEMU's websocket:
+https://bugs.launchpad.net/qemu/+bug/1718964
+
+It has been fixed but someone mentioned that he met the same problem when using QEMU with a standalone websocket proxy.
+That makes me confused because in that scenario QEMU will get a "RAW" VNC connection.
+So I did a test and found that there indeed existed some problems. The problem is:
+
+When the client's network is poor (on a low speed WAN), QEMU still sends a lot of data to the websocket proxy, then the client get stuck. It seems that only QEMU has this problem, other VNC servers works fine.
+
+Environment
+-------------------------
+All of the following versions have been tested:
+
+QEMU: 2.8.1.1 / 2.9.1 / 2.10.1 / master (Up to date)
+Host OS: Ubuntu 16.04 Server LTS / CentOS 7 x86_64_1611
+Websocket Proxy: websockify 0.6.0 / 0.7.0 / 0.8.0 / master
+VNC Web Client: noVNC 0.5.1 / 0.61 / 0.62 / master
+Other VNC Servers: TigerVNC 1.8 / x11vnc 0.9.13 / TightVNC 2.8.8
+
+Steps to reproduce:
+-------------------------
+100% reproducible.
+
+1. Launch a QEMU instance (No need websocket option):
+qemu-system-x86_64 -enable-kvm -m 6G ./win_x64.qcow2 -vnc :0
+
+2. Launch websockify on a separate host and connect to QEMU's VNC port
+
+3. Open VNC Web Client (noVNC/vnc.html) in browser and connect to websockify
+
+4. Play a video (e.g. Watch YouTube) on VM (To produce a lot of frame buffer update)
+
+5. Limit (e.g. Use NetLimiter) the client inbound bandwidth to 300KB/S (To simulate a low speed WAN)
+
+6. Then client's output gets stuck(less than 1 fps), the cursor is almost impossible to move
+
+7. Monitor network traffic on the proxy server
+
+Current result:
+-------------------------
+Monitor Downlink/Uplink network traffic on the proxy server
+(Refer to the attachments for more details).
+
+1. Used with QEMU
+- D: 5.9 MB/s U: 5.7 MB/s (Client on LAN)
+- D: 4.3 MB/s U: 334 KB/s (Client on WAN)
+
+2. Used with other VNC servers
+- D: 5.9 MB/s U: 5.6 MB/s (Client on LAN)
+- D: 369 KB/s U: 328 KB/s (Client on WAN)
+
+It is found that when the client's network is poor, all the VNC servers (tigervnc/x11vnc/tightvnc) 
+will reduce the VNC data send to websocket proxy (uplink and downlink symmetry), but QEMU never drop any frames and still sends a lot of data to websockify, the client has no capacity to accept so much data, more and more data are accumulated in the websockify, then it crashes.
+
+Expected results:
+-------------------------
+When the client's network is poor (WAN), QEMU will reduce the VNC data send to websocket proxy.
\ No newline at end of file