> I don't know the reason :) but have you tried to uninstall VNC, > remove all VNC related parameters from registry, reboot the machine and > install VNC again? Don't forget to register VNC service.
No, I haven't tried this yet. Though this happens on windows machines, I truly doubt that such methods really solve problems. VNC behaves a way it shouldn't and I'd rather find a way to solve this than looking for a workaround that I maybe would have to use on future installations as well. If this is a bug in VNC, it's good to locate it. If this is my fault, it's good that I learn what I have made wrong. > OTOH, I don't understand your reasoning on SSH. I have received mails from people that told me that they had the same problem on their machines and they solved it by changing the NIC. They assumed that the NIC maybe could change a bit in a packet somewhere. I wanted to prove that this cannot be the reason (though I never believed that this could be the reason, but you never know). > If your two > machines are connected to the network, and if the network isn't stable > (eg, packet loss) They were especially writing about bits that may "change" within a packet. > I don't see how SSH can resolve it. In TCP bits in a packet can change without TCP getting notice of this, because the checksum algorithm is quite weak. It's not very probable, but it's possible. Though the probability that this happens in a particular packet is very low, the amount of packets that is being transmitted over such connection makes it probable, that this can happen. Theoretically such "driver problem" could occur and be reproducible, anytime exactly the same conditions are given. This is the case when someone is opening a connection to a VNC-server. So _theoretically_ this can happen. I was basically doing this to prove to the people that told me that my problem is a driver or NIC problem, that this isn't the case. > SSH is just like > TCP or UDP which are built on top of IP. If the underlying IP experience > problem (in Data Link Layer or Physical Layer), there's no reason why SSH > would be saved. SSL (not SSH) has a much stronger algorithm assuring that the packets are received exactly the way they have been sent. If such a theoretical thing like a "driver problem" or a "NIC that changes some bits sometimes" really would happen, SSL would keep on re-requesting that packet (or die in the end), because the packet could not be decrypted at all. It's infeasible to change bits in SSL-packets without SSL getting notice about this. -- Regards, T. _______________________________________________ VNC-List mailing list [EMAIL PROTECTED] To remove yourself from the list visit: http://www.realvnc.com/mailman/listinfo/vnc-list
