Open Source Guacamole Puts VNC On the Web

tbitiss writes "A new open source project dubbed Guacamole allows users to access a desktop remotely through a web browser, potentially streamlining the requirements for client support and administration. Guacamole is an HTML5 and JavaScript (Ajax) VNC viewer that makes use of a VNC-to-XML proxy server written in Java. According to its developers, Guacamole is almost as responsive as native VNC and should work in any browser supporting the HTML5 canvas tag. Supporting 10 Linux desktops in 10 browser tabs? I like the sound of that."

Re:Slashvertisement?

[dotancohen]

Ack! TFA (yeah, I went for it) splashes some ad that didn't make it past my hosts file. You might want this link instead, which goes to the sourceforge page and not the techworld blog:
http://sourceforge.net/projects/guacamole/ [sourceforge.net]

Back ... TO THE FUTURE!

[Jeffrey Baker]

Plain old vncserver had this capability since at least 1998. I remember using it once at a customer site and their staff gathered around gawking. "He's got xterms in Netscape!"

Re:Unencrypted

[tepples]

If you type passwords into a VNC session, you definitely want to tunnel it through something secure.

Fortunately, HTTP has been tunneled over TLS [wikipedia.org] since TLS was called SSL.

Re:Back ... TO THE FUTURE!

[Anonymous Coward]

Yeah, but not with XML, Javascript and HTML5. That was a Java applet. So not cool.

Re:bucng of layers

[physburn]

Yes please, lets turn all the screen output to XML, before turning it back to screen output, because XML, is so cool. That would be so much faster than streaming X11 (not).

Re:TightVNC too

[Anonymous Coward]

Actually, the javaVNC daemon was included in the original AT&T Proof of Concept. However, VNC and the Java applet use TCP ports 58xx and 59xx -- the whole thing about this version is that it can pass data over the HTTP stream on TCP 80 and TCP 443 -- meaning you don't have to punch holes in your router's firewall. They run the java app on the server side and translate the output so it can be pushed via HTTP instead of the proprietary VNC data stream blocks.

Personally, I think it would be easier to add some new encodings to VNC that happen to be SOAP/HTML5/JS etc. compatible; then all you'd have to do is inject the VNC feed into an HTTP datafeed, without having to worry about all this abstraction and translation. Since the Java server contains an HTTP server anyway, they could even push it directly to this feed, bypassing the traditional VNC data feed/java applet combo.

Re:Great....

[NormalVisual]

It's not a matter of it being open source. VNC is sending huge blocks of pixel data anytime anything changes on the source display, whereas RDP sends much more high-level commands which the client can then use to reconstruct the desktop locally instead of having to retrieve each and every pixel across the wire. XDMCP is another protocol that's somewhat comparable to RDP, and takes advantage of the fact that the X window system was designed to work over a network and thus sends X commands instead of big blocks of pixels. XDMCP offers performance light-years better from the user's perspective than VNC in my experience, and I find it to be almost indistinguishable from sitting at the workstation itself when used over a 100 megabit network. NX is similar to XDMCP in concept, but offers a number of improvements and generally performs better.

Also, RDP is a Windows-specific, proprietary protocol, so while there are Unix RDP clients that can connect to a Windows server, the fundamental differences in the way X and Windows generate their displays make it difficult to create a good RDP server for non-Windows systems. VNC's performance is usually pretty awful, but because it's just moving blocks of pixels around it's fairly easy to create a VNC server for any operating system.

Re:Name?

[oatworm]

If I had mod points, I would give you all of them.

Re:Great....

[Abcd1234]

The X11 folks tried to fix that by creating Low-Bandwidth X (LBX), which may be what you're thinking of. It never really took off, both because it didn't really help much and few commercial Unix vendors (remember them?) bothered to implement it.

Nah, he probably just got his acronyms mixed up. My bet is he really meant the Differential X Protocol Compressor [vigor.nu], or DXCP for short. DXCP would be the precursor technology that lead to NX.