NX protocol support about novnc HOT 15 CLOSED

-1. I think it's better to keep the browser side implementation small, minimal and fast. Protocol conversions can be done on the server side instead.

from novnc.

closing due to age.

from novnc.

Explanation of the NX protocol:
http://www.nomachine.com/documents/NX-XProtocolCompression.php

from novnc.

I am considering working on this as it would be a core part of integrating into our linux server offerings although we use x2go for the servers which uses a modified nx protocol

from novnc.

@cryptomole: awesome!

Before you commit too much time or resources to the project, I would suggest doing some performance testing to determine feasibility. While Javascript performance across the board has increased by orders of magnitude in the past few years, it's still not nearly as fast as native code and performance varies widely depending on what you are doing. For example, Javascript has historically (and still is) very poor at doing bit-wise math operations. This makes it too slow for doing real-time zlib/deflate of large chunks of pixel data.

If zlib compression/decompression of pixel data is a mandatory part of NX (or x2go) then Javascript is probably too slow to make a usable client. For example, I ruled out doing the zlib/tight encoding in noVNC because it requires zlib encoded pixel data and that turned out to be too slow.

However, even if NX/x2go has mandatory zlib compression of pixel data there are a couple of options if you are really committed to moving forwards with this:

• The specifications that define the web applications (colloquially called HTML5), are currently in rapid flux and there is an opening to get in important functionality. For example, there is the DOM Crypto proposal (https://wiki.mozilla.org/Privacy/Features/DOMCryptAPISpec/Latest) for providing a DOM/Javascript API to do cryptography. I am considering drafting a proposal for a deflate/inflate (zlib) API to the DOM/Javascript API set since there are a lot of cases where that would be useful. Unfortunately, I'm pretty busy and not sure if I'll get around to this.
• Extend the x2go/NX protocol with a new encoding that uses PNG data instead of zlib for the pixel data. Last year I worked with a google summer of code student to define a new VNC/RFB encoding format called tightPNG. TightPNG is basically the tight encoding but instead of zlib encoded pixel data, it uses PNG image data in its place. PNG images in fact use zlib encoded pixel data internally, but the benefit from a browser/Javascript perspective is that PNG image data can be drawn directly to a canvas object without any zlib/inflate in Javascript (the browser handles the decode/render internally in native code). TightPNG is now supported in in the QEMU VNC server and also in a branch of libvncserver (with current discussion on the libvncserver mailing list about incorporating it upstream).

Keep me posted. I won't be able to be directly involved due to current time limitations, however, I would love to answer any questions you have (especially about noVNC structure/functionality or Javascript performance issues) to help you along.

from novnc.

BTW, there are a couple of reasons for the "no" in the noVNC name. The first is that there is no application to install (just runs in the browser) and the second more subtle reason is that I have always intended that noVNC would support more than just VNC/RFB (such as RDP, NX, Spice, etc). I haven't gotten around to other protocols yet, but I've tried to keep the code fairly modular and keep VNC/RDP functionality separate from the rest:

• include/vnc.js dynamically includes all the Javascript files necessary to implement a VNC client.
• include/rfb.js implements the RFB protocol (VNC) itself.
• include/ui.js implements the default example UI (controls, menu) which is not really designed to be used by project integrators.
• Mouse, keyboard, network, display/canvas functions are all implemented in separate includes files.

See this wiki for more details: https://github.com/kanaka/noVNC/wiki/ModulesAPI

from novnc.

i still have to look into the protocol a bit more one of ways we have avoided the zlib issue is to extend the proxy to do the decompression although this effects bandwidth out systems we sell are use on local networks so this has not been an issue for us will keep you updated on what we decide to do

from novnc.

@astrand, noVNC has a modular design and I always intended for it support more than just VNC/RFB (the name is sort of a play on that fact).

My long-term goal for noVNC is that it supports a wide range of remote frame buffer protocols directly in the browser: RDP, NX, Spice, etc.

Another long-term goal is that noVNC can talk directly to the servers hosting those services without requiring those services to do translation and protocol conversion for noVNC. We aren't there yet because we still require websockify to bridge between WebSockets and TCP sockets for most VNC servers. However, libvncserver already directly supports WebSocket connections from noVNC (no bridge needed) and I would like to see more VNC server support WebSockets directly). Another reason this is a long term goal is that Javascript may not be quite fast enough to do zlib inflate efficiently enough for compressed protocols. That's yet to be determined: I'm waiting on somebody to implement the first zlib based encoding in noVNC :-). But certainly, with the type hinting support in recent firefox Javascript engines, zlib is going to be feasible if it isn't already.

I want noVNC to be fast, modular and well designed, but small and minimal are not direct goals (that's fine if it ends up that way but not at the expense of other things). And websockify should also remain a dumb bridge between WebSockets and TCP sockets.

from novnc.

I think that finding a fast zlib library on javascript is not longer a problem. See issue #25

I have just also checked that the nomachine guys are developing a webclient for the NX protocol http://www.nomachine.com/web-player.php However is not clear to me how they are doing this.

from novnc.

Yep, jsunzip turns out to be quite fast. I suspect that the NX Web Player is more like Guacamole in which the server does all the work by parsing the encoding into simple PNG/JPEG images which are sent to the client to display. In other words, I suspect that the NX Web Player is not actually an NX protocol client, but rather a simple event handler and image display engine.

That does reduce the priority of adding NX protocol support to noVNC, however, I still think it would be interesting and would be willing to add it if somebody is willing to do the work.

from novnc.

Which way do you think is best efficient for low bandwidth links (modems/gsm) ? The one where the servers sends png/jpeg images like guacamole or the one that novnc implements handling directly the protocol?

Take into account that this nomachine web player is proprietary and closed software, so I don't think that this reduces the priority for adding NX protocol to noVNC.

We are using X2GO and we are quite happy with it, so we definitively would love to see noVNC supporting the NX protocol and its variants (like X2GO)

from novnc.

I can't say for sure because it highly dependent on both the way the protocol encodes data and and how smart the server side of the Web Player is. It also depends on what type of thing you are doing (console vs UI vs UI+video).

The PNG format uses zlib compression, so it comparable to the VNC tight encoding when used without high compression via jpeg.

The algorithm the server uses for detecting changed areas also makes a big difference in bandwidth. For example, many tight VNC servers try and detect video or rapidly changing areas of the screen and switch to sending those areas of the screen as lossy jpeg encoded regions. The NX Web Player may or may not do that.

How tightly the Web Player is integrated with the NX server itself will make a big difference.

One way that remote desktops can be accelerated (and bandwidth usage dropped) is by caching common images (icons, window borders, menus, etc), but this requires that the server have knowledge or where these begin and end (or require heuristics in the server to guess). The Web Player may or may not do caching of images on the browser side (my guess is not). Even some VNC client/servers will do caching by using a desktop that is actually bigger than either client or server frame buffer and using the extra space around the edges for common images (and then just copying from that edge area to where the image actually is showing).

In other words, you'll probably just need to do some testing of actual configurations. If the Web Player can be run on a separate server from the NX server itself, then you could compare the bandwidth between the Web Player server to the NX server and between the browser and the Web Player for the same session. Note, I'm not familiar with how Web Player works, so it may just be a mode of running the NX server itself and not a standalone service (the way that websockify and Guacamole are).

If you can't do that, then you could do two separate sessions, one with the Web Player and one with a normal NX client (note that some remote frame buffer clients will detect local networks and often use a less efficient but lower latency encoding) and try and do the same actions for the same amount of time to see if you can measure approximate difference.

from novnc.

Yesterday I was testing X2GO and tightvnc (with the more aggressive tight encoding) over a low bandwidth link (GSM) and the funny thing is that tightvnc required less bandwidth to work more or less seamlessly (over 6kbyte/sec) than X2GO (over 12kbyte/sec).

However the user experience on X2GO was feeling much more responsive than on tightvnc.

Digging about this I found this paper http://cseweb.ucsd.edu/~cbtaylor/cns1_2009.pdf about an implementation of an smart proxy for VNC in order to improve the latency.

I believe that NX (X2GO) uses some technique like the one described on this paper.

What do you think about implementing some kind of smart proxy on the noVNC WebSockets-TCP proxy like the one described on the paper?

from novnc.

A proxy is only a band aid, if you cannot solve it for real in the server and client. When it comes to latency, you might be interested in reading what my collegue at Cendio has written here: http://sourceforge.net/apps/mediawiki/tigervnc/index.php?title=VNC_Latency_Considerations

The proposed solution has been integrated into TigerVNC, with very good result. The protocol changes has also been included in the community version of the protocol, se: http://sourceforge.net/apps/mediawiki/tigervnc/index.php?title=Main_Page#RFB_Protocol

My suggestion is that we should add support for these mechanisms to noVNC.

from novnc.

@astrand, feel free to file an issue ticket (this current issue is a feature request for NX protocol support).

I'm not committing to do it, but it's certainly interesting extensions that would probably be worthwhile and I would consider contributions that implement it.

from novnc.