Connection closes

Seak, Teng-Fong tfseak "at"
Thu Jan 29 15:02:00 2004

	From your another post, I knew that your connection problem has been solved.  Congratz!

> -----Message d'origine-----
> De : T. Valent [mailto:winsock2 "at"]
> Envoyi : lundi 26 janvier 2004 20:01
> @ : Seak, Teng-Fong; VNC-List "at"
> 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.


> > 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.