TightVNC 1.2.2, is it beneficial?
tng "at" cyberus.ca
Tue, 12 Feb 2002 05:11:41 +0000
At 10:06 AM 2002-02-08, you wrote:
> >From: "Moreland, Julius" <Julius.Moreland "at" ci.corvallis.or.us>
> >Date: Fri Feb 8 2002 10:06am
> >To: "'vnc-list "at" uk.research.att.com'" <vnc-list "at" uk.research.att.com>
> >Subj: TightVNC 1.2.2, is it beneficial?
> >I am considering deploying this to our clients in place of VNCr9.
> >Does anyone have an opinion on this version of Tight VNC?
> >Any raves or rants?
The greatest advantage of TightVNC over WinVNC I have found is that the bug
which eats up all your system resources on a Win9x machine and potentially
crashing the machine is fixed as of TightVNC 1.2.2. I use VNC to provide
remote support and it just wasn't accomplishing the desired effect when the
initial connection over a modem would crash the computer of the person I
was supposed to be helping.
An important fact for me is that unlike WinVNC, I see TightVNC actively
being developed which means that there is a better chance of a bug getting
fixed sooner with TightVNC than with WinVNC.
At least one of the WinVNC developers used to lurk and occasionally comment
in the vnc-list but I haven't seen any messages from him in quite a while
(are you still around James?). On the other hand, maybe he is hard at work
on the next release. Who knows...
There are also many other great TightVNC features not available in WinVNC
such as logging, user authentication (prompting the user to accept the
connection), better data compression, local mouse and cursor and more. When
running the server, just click on the Advanced button to see all of the
sever enhancements. For the client, just click the "Options" button of the
Connection Details dialogue.
By the way, there is nothing preventing you from installing WinVNC and
TightVNC on the same machine. I don't recommend running them both at the
same time although you can run the server from one and the client of the
other. However to get the full benefit of TightVNC you should of course be
running TightVNC on both the server and the client.
It would be nice if the author of TightVNC would add data encryption to the
package. I suspect that this might (hopefully) be added in a future release.
Now for the downside of TightVNC. I have occasionally found that screen
refreshes take a longer to happen with TightVNC than WinVNC. When it
happens, it almost seems like the TightVNC client gets very busy doing
something because I don't see any data coming across. Finally the screen
update happens all of a sudden, out of the blue, usually just as I am about
to close the connection. This happens most often when connecting to a
WinVNC host. Unfortunately I can not reproduce the problem on demand and
certainly not when I am trying to demonstrate the problem.
Just about as often, try as I may, I get into a situation where I am unable
to convince the TightVNC client that the client and host screens are
different, even if I click the Request Screen Refresh option. Disconnecting
and reconnecting again seems to fix the problem. I haven't complained about
it yet because I can't seem to reproduce the problem with any degree of
reliability whatsoever. Being a programmer myself, I know that it is
extremely difficult and most of the time impossible to fix a problem if you
can't reproduce it. I can say that it appears to happen mostly when the
connection is over a wireless network where the speed of the connection
fluctuates and may occasionally disconnect briefly (I have no idea though
if that fact is related). However this is by no means the only situation in
which it happens.
As far as reliability is concerned, both TightVNC and WinVNC have served me
well for a long time but these days I tend to rely more on TightVNC for my
remote screen takeover needs.
About the only tip that I can offer is that you try to avoid a mixed
WinVNC/TightVNC environment. Most of the reliability issues I have come
across occurred when connecting to a WinVNC host server. If you have to run
mixed, I would recommend TightVNC hosts across the board as it appears to
be more stable, reliable and leaks less system resources on Win9x/ME
machines regardless of which client, WinVNC or TightVNC, you use.
Constantin appears to have done a great job ironing out a lot of the server
bugs since the release R9 of WinVNC.
Hope this helps.
To unsubscribe, mail majordomo "at" uk.research.att.com with the line:
'unsubscribe vnc-list' in the message BODY
See also: http://www.uk.research.att.com/vnc/intouch.html