winsock2 "at" musiker.de
Mon Jan 26 19:01:01 2004
> 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.