Re: Disconnect when switching users XP

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Thanks. With the many customers I connect with, it sounds like it is safer to keep RealVNC or risk not being able to connect to customer. 

To bad real doesn't push the technology standards up. 

Sent from my iPod Touch. 
The further I look through the pain of glass in Windowz, the further I see and I see a Mac on the horizon. 

On Mar 15, 2011, at 5:26 PM, Peter Rosin <peda@xxxxxxxxxxxxxx> wrote:

> 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@xxxxxxxxxxx
> To remove yourself from the list visit:
> http://www.realvnc.com/mailman/listinfo/vnc-list

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


[Index of Archives]     [Spice Remote Desktop for Virtual Machines]     [Yosemite Questions]     [Open Source Now]
  Powered by Linux