From your another post, I knew that your connection problem has been solved. Congratz!
> -----Message d'origine----- > De : T. Valent [mailto:[EMAIL PROTECTED] > Envoyi : lundi 26 janvier 2004 20:01 > @ : Seak, Teng-Fong; [EMAIL PROTECTED] > Objet : RE: Connection closes > > > 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 If you hadn't doubted about such method, you might have probably solved your problem as well, although you might not know the real reason behind :-) > 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). OK, I now see your point. Actually, in your first post, you had just told us that you had tried SSL, but I didn't quite catch your point. Anyway, I don't think this discussion would interest you anymore, so I stop here, even though some of the points below left debatable. Bye > > 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
