readme

JAVA版vpn客户端,是在web上实现远程访问的最佳方式.

  TightVNC Java Viewer version 1.3.9

======================================================================

This distribution is based on the standard VNC source and includes new
TightVNC-specific features and fixes, such as additional low-bandwidth
optimizations, major GUI improvements, and more.

	Copyright (C) 1999 AT&T Laboratories Cambridge.
	Copyright (C) 2000 Tridia Corp.
	Copyright (C) 2002-2003 RealVNC Ltd.
	Copyright (C) 2001-2004 HorizonLive.com, Inc.
	Copyright (C) 2000-2007 Constantin Kaplinsky
	Copyright (C) 2000-2007 TightVNC Group
	All rights reserved.

This software is distributed under the GNU General Public Licence as
published by the Free Software Foundation. See the file LICENCE.TXT for the
conditions under which this software is made available. TightVNC also
contains code from other sources. See the Acknowledgements section below, and
the individual files for details of the conditions under which they are made
available.


Compiling from the sources
==========================

To compile all the .java files to .class files, simply do:

	% make all

This will also generate a JAR (Java archive) file containing all the classes. 
Most JVM (Java Virtual Machine) implementations are able to use either a set
of .class files, or the JAR archive.


Installation
============

There are three basic ways to use TightVNC Java viewer:

  1. Running applet as part of TightVNC server installation.

     Both the Unix and Windows versions of TightVNC servers include small
     built-in HTTP server which can serve Java viewer to Web clients. This
     enables easy Web access to the shared desktop without need to install
     any software on the client computer. Unix and Windows versions of
     TightVNC servers are different in the way they store the .class and .jar
     files: the Unix server (Xvnc) is able to serve any set of files present
     in a particular directory, while the Windows server (WinVNC) has all the
     .class and .jar files inside the WinVNC executable file. Therefore, for
     Xvnc, it's enough to copy the files into a correct directory, but for
     WinVNC, the server binaries should be rebuild if the built-in Java
     viewer should be updated.

     To install the Java viewer under Xvnc, copy all the .class files, the
     .jar file and the .vnc files to an installation directory (e.g.
     /usr/local/vnc/classes):

         cp *.class *.jar *.vnc /usr/local/vnc/classes

     Also, make sure that the vncserver script is configured to point to the
     installation directory (see the Xvnc manual page for the description of
     the -httpd command-line option).

  2. Running applet hosted on a standalone Web server.

     Another possibility to use the Java viewer is to install it under a
     fully-functional HTTP server such as Apache or IIS. Obviously, this
     method requires running an HTTP server, and due to the Java security
     restrictions, it's also required that the server should be installed on
     the same machine which is running the TightVNC server. In this case,
     installation is simply copying the .class and .jar files into a
     directory that is under control of the HTTP server. Also, an HTML page
     should be created which will act as a the base document for the viewer
     applet (see an example named index.html in this distribution).

     NOTE: Provided index.html page is an example only. Before using that
     file, edit it with a text editor. See more information inside
     index.html.

  3. Running the viewer as a standalone application.

     Finally, the Java viewer can be executed locally on the client machine,
     but this method requires installation of either JRE (Java Runtime
     Environment) or JDK (Java Development Kit). If all the .class files are
     in the current directory, the Java viewer can be executed like this,
     from the command line:

         java VncViewer HOST vnchost PORT 5900

     The parameters HOST and PORT are required, but there is a number of
     optional parameters as well (see the Parameters section below).

Parameters
==========

TightVNC Java viewer supports a number of parameters allowing you to
customize its behavior. Most parameters directly correspond to the settings
found in the Options window. However, there are parameters that do not
correspond to those settings. For such parameters, you can see a note "no GUI
equivalent", in the documentation below.

Parameters can be specified in one of the two ways, depending on how the Java
viewer is used:

  1. When the Java viewer is run as an applet (embedded within an HTML
     document), parameters should be specified in the <PARAM> HTML tags,
     within the appropriate <APPLET> section. Here is an example:

    <APPLET CODE=VncViewer.class ARCHIVE=VncViewer.jar WIDTH=400 HEIGHT=300>
      <PARAM NAME="PORT" VALUE=5901>
      <PARAM NAME="Scaling factor" VALUE=50>
    </APPLET>

  2. When run as a standalone application, the Java viewer reads parameters
     from the command line. Command-line arguments should be specified in
     pairs -- first goes parameter name, then parameter value. Here is a
     command line example:

     java VncViewer HOST vnchost PORT 5901 "Scaling factor" 50

Both parameter names and their values are case-insensitive. The only
exception is the "PASSWORD" parameter, as VNC passwords are case-sensitive.

Here is the complete list of parameters supported in TightVNC Java viewer:

--> "HOST" (no GUI equivalent)

    Value: host name or IP address of the VNC server.
    Default: in applet mode, the host from which the applet was loaded.

    This parameter tells the viewer which server to connect to. It's not
    needed in the applet mode, because default Java security policy allow
    connections from applets to the only one host anyway, and that is the
    host from which the applet was loaded. However, this parameter is
    required if the viewer is used as a standalone application.

--> "PORT" (no GUI equivalent)

    Value: TCP port number on the VNC server.
    Default: none.

    This parameter is required in all cases. Note that this port is not the
    one used for HTTP connection from the browser, it is the port used for
    RFB connection. Usually, VNC servers use ports 58xx for HTTP connections,
    and ports 59xx for RFB connections. Thus, most likely, this parameter
    should be set to something like 5900, 5901 etc.

--> "PASSWORD"

    Value: session password in plain text.
    Default: none, ask user.

    DO NOT EVER USE THIS PARAMETER, unless you really know what you are
    doing. It's extremely dangerous from the security point of view. When
    this parameter is set, the viewer won't ever ask for a password.

--> "ENCPASSWORD"

    Value: encrypted session password in hex-ascii.
    Default: none, ask user.

    The same as the "PASSWORD" parameter but DES-encrypted using a fixed key.
    Its value should be represented in hex-ascii e.g. "494015f9a35e8b22".
    This parameter has higher priority over the "PASSWORD" parameter. DO NOT
    EVER USE THIS PARAMETER, unless you really know what you are doing. It's
    extremely dangerous from the security point of view, and encryption does
    not actually help here since the decryption key is always known.

--> "Encoding"

    Values: "Auto", "Raw", "RRE", "CoRRE", "Hextile", "ZRLE", "Zlib", "Tight".
    Default: "Auto".

    The preferred encoding. If the value is "Auto", then the viewer will
    continuously estimate average network throughput and request encodings
    that are appropriate for current connection speed. "Hextile" is an
    encoding that was designed for fast networks, while "Tight" is better
    suited for low-bandwidth connections. From the other side, "Tight"
    decoder in the TightVNC Java viewer seems to be more efficient than
    "Hextile" decoder so it may be ok for fast networks too. "ZRLE" encoding
    is similar to "Tight", but it does not support JPEG compression and
    compression levels. Unlike "Tight" encoding, "ZRLE" is supported in
    recent versions of RealVNC products. Other encodings are not efficient
    and provided for compatibility reasons.

--> "Compression level"

    Values: "Default", "1", "2", "3", "4", "5", "6", "7", "8", "9".
    Default: "Default". ;-)

    Use specified compression level for "Tight" and "Zlib" encodings. Level 1
    uses minimum of CPU time on the server but achieves weak compression
    ratios. Level 9 offers best compression but may be slow in terms of CPU
    time consumption on the server side. Use high levels with very slow
    network connections, and low levels when working over higher-speed
    networks. The "Default" value means that the server's default compression
    level should be used.

--> "JPEG image quality"

    Values: "JPEG off", "0", "1", "2", "3", "4", "5", "6", "7", "8", "9".
    Default: "6".

    Use the specified image quality level in "Tight" encoding. Quality level
    0 denotes bad image quality but very impressive compression ratios, while
    level 9 offers very good image quality at lower compression ratios. If
    the value is "JPEG off", the server will not use lossy JPEG compression
    in "Tight" encoding.

--> "Cursor shape updates"

    Values: "Enable", "Ignore", "Disable".
    Default: "Enable".

    Cursor shape updates is a protocol extension used to handle remote cursor
    movements locally on the client side, saving bandwidth and eliminating
    delays in mouse pointer movement. Note that current implementation of
    cursor shape updates does not allow a client to track mouse cursor
    position at the server side. This means that clients would not see mouse
    cursor movements if mouse was moved either locally on the server, or by
    another remote VNC client. Set this parameter to "Disable" if you always
    want to see real cursor position on the remote side. Setting this option
    to "Ignore" is similar to "Enable" but the remote cursor will not be
    visible at all. This can be a reasonable setting if you don't care about
    cursor shape and don't want to see two mouse cursors, one above another.

--> "Use CopyRect"

    Values: "Yes", "No".
    Default: "Yes".

    The "CopyRect" encoding saves bandwidth and drawing time when parts of
    the remote screen are moving around. Most likely, you don't want to
    change this setting.

--> "Restricted colors"

    Values: "Yes", "No".
    Default: "No".

    If set to "No", then 24-bit color format is used to represent pixel data. 
    If set to "Yes", then only 8 bits are used to represent each pixel. 8-bit
    color format can save bandwidth, but colors may look very inaccurate.