Den 2011-03-15 17:48 skrev Long, Phillip GOSS:
> Dale:
> 
> We use UltraVNC on our Windows machines, and it's free as far as I 
> know (I'm not involved in licensing and that kind of noise).  I 
> have had better luck with the UVNC server than with the Real one, 
> but the vncviewer works about the same.  RealVNC maintains the 
> protocol, and when UVNC, TightVNC, etc., want to create some new 
> kind of packet, they apply to RealVNC for a number, and AFAIK, 
> RealVNC gladly hands it out.  I'm guessing that UVNC was written 
> by guys more familiar with MSWindows (only because it's not on 
> other platforms, not because of code quality; I haven't really 
> compared the codebases).  I think the protocol is designed so that 
> unknown packet types are ignore/dropped, so that a viewer and a 
> server can always talk to one another, provided that they're both 
> using the same *version* of the protocol.  That's the beauty of 
> RealVNC maintaining the protocol for everybody; all the various 
> flavors can all talk with one another (again, if they use the 
> same version).  If U're having trouble with a viewer and a server 
> from different packages not communicating, it could be because 
> they're not both using the same version of the protocol.

But UltraVNC is not conforming to the protocol. The UltraVNC client
has a chance to work with all other *current* RFB conforming servers,
but a client that is strictly conforming to the RFB protocol cannot
communicate with the UltraVNC server.

UltraVNC extended the protocol without coordinating with the RealVNC
protocol maintainers, and as a result everybody else must select
if they should have warts in the code that is outside the specs (and
a possible broken implementation should RealVNC decide to use the
mechanism used by UltraVNC for something of their liking) or drop
support for communicating with the UltraVNC server outright.

UltraVNC is in the embrace-and-extend camp and is a nasty piece of
work if you ask me.  Sure, other implementations also extend the
RFB protocol, but most do it without sacrificing interoperability.
Or, at least they try to.

Caveat emptor: This was the situation last time I had a look, but
I doubt it has changed since.

Cheers,
Peter

_______________________________________________
VNC-List mailing list
VNC-List@realvnc.com
To remove yourself from the list visit:
http://www.realvnc.com/mailman/listinfo/vnc-list

Reply via email to