Re: [rfbproto] VNC high latency update
On Sun, 19 Feb 2012 23:32:22 +0530 vasanth kumar d.vas...@gmail.com wrote: Hi, I was going through protocol improvement technique for high latency networks. I adopted your continuous update technique but pausing the updates if send data pushed is more than the congestion window. Windows vista above provides APIs to get the congestion window , with this value we can get the maximum send bytes that can be kept on wire without getting acknowledgement. Nice to see someone else implementing this. :) In TigerVNC we purposefully avoid getting congestion window information from the operating system. The reason for this is that we need to know the congestion for the entire pathway between the server and viewer, which might involve more than one TCP connection (proxies). This is why I also added the Fence extension at the same time as it allows the server to measure the congestion independently of the transport layer. I replaced UVNC server with the above implementation created a separate sourceforge project. You can test the implementation provide me feedback if you find it interesting. http://sourceforge.net/projects/cloudvnc/ Was upstream UltraVNC not interested in these improvements? Rgds -- Pierre OssmanOpenSource-based Thin Client Technology System Developer Telephone: +46-13-21 46 00 Cendio ABWeb: http://www.cendio.com A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? signature.asc Description: PGP signature -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2___ tigervnc-rfbproto mailing list tigervnc-rfbproto@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-rfbproto
Re: [rfbproto] VNC high latency update
Hi Pierre Ossman, Thanks for your reply. I posted in UVNC forum about it but i didn't get any feedback yet. regards, vasanth On Mon, Feb 20, 2012 at 2:14 PM, Pierre Ossman oss...@cendio.se wrote: On Sun, 19 Feb 2012 23:32:22 +0530 vasanth kumar d.vas...@gmail.com wrote: Hi, I was going through protocol improvement technique for high latency networks. I adopted your continuous update technique but pausing the updates if send data pushed is more than the congestion window. Windows vista above provides APIs to get the congestion window , with this value we can get the maximum send bytes that can be kept on wire without getting acknowledgement. Nice to see someone else implementing this. :) In TigerVNC we purposefully avoid getting congestion window information from the operating system. The reason for this is that we need to know the congestion for the entire pathway between the server and viewer, which might involve more than one TCP connection (proxies). This is why I also added the Fence extension at the same time as it allows the server to measure the congestion independently of the transport layer. I replaced UVNC server with the above implementation created a separate sourceforge project. You can test the implementation provide me feedback if you find it interesting. http://sourceforge.net/projects/cloudvnc/ Was upstream UltraVNC not interested in these improvements? Rgds -- Pierre OssmanOpenSource-based Thin Client Technology System Developer Telephone: +46-13-21 46 00 Cendio ABWeb: http://www.cendio.com A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2___ tigervnc-rfbproto mailing list tigervnc-rfbproto@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-rfbproto
[rfbproto] VNC high latency update
Hi, I was going through protocol improvement technique for high latency networks. I adopted your continuous update technique but pausing the updates if send data pushed is more than the congestion window. Windows vista above provides APIs to get the congestion window , with this value we can get the maximum send bytes that can be kept on wire without getting acknowledgement. I use overlapped send for sending updates to the viewer. If the overlapped send pending bytes is more than the congestion window, i notify the screen update thread to stop sending updates. This seems to provide quick responsiveness smooth animation in viewer side without any changes. Normally, most VNC server implementation uses static send socket buffering which won't suit for high latency or low bandwidth networks. The static value would introduce network delays if the value is very higher than the changing congestion window. I replaced UVNC server with the above implementation created a separate sourceforge project. You can test the implementation provide me feedback if you find it interesting. http://sourceforge.net/projects/cloudvnc/ I would also be interested to update the code changes to tigervnc if it makes difference. Regards, vasanth -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/___ tigervnc-rfbproto mailing list tigervnc-rfbproto@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-rfbproto
