Analysis of VNC protocol
Original link: http://blog.csdn.net/forever_feng/archive/2009/10/20/4703088.aspx
VNC (Virtual network Computing) is based on the RfB (Remote Frame Buffer) protocol to communicate, is a platform-independent simple display protocol of the Super thin Customer system,
Designed and developed by Cambridge's AT&T laboratory.
The default port for VNC is main:5900 (c/s) and http:5800 (b/s) ports.
RFB (remote frame caching) is a simple protocol for a remote graphical user, because it works at the frame cache level, so it can be applied to all window systems, such as the X11,windows and Mac systems.
Remote end users use machines (such as monitors, keyboards, mice) called RFB clients, which provide frame cache changes called RfB servers.
RfB is an application layer protocol based on TCP.
RFB is the true meaning of the "thin airliner" agreement. The focus of the RfB protocol design is to reduce the hardware requirements for the client. This allows the client to run on many different hardware, and the client's task implementation will be as simple as possible.
The RFB protocol is stateless for the client. In other words: If the client disconnects from the server, the client's state is saved if it is reconnected to the same server. Even a different client can be used to connect to the same RfB server. The new client already has the same user status as the previous client. Therefore, the user's application interface becomes very convenient.
As long as the right network connection exists, users can use their own applications, and these applications will be saved, even at different access points. In this way, the system will provide users with a familiar and unique computing environment.
The display protocol is based on the single figure "Place the pixel data in a box positioned by the x,y."
At first glance, it's a very inefficient way to draw so many user interface components. However, by allowing different pixel data encoding methods, we have a great deal of flexibility in dealing with different parameters such as network bandwidth, client drawing speed, server processing speed, and so on.
Completes the update of the frame cache through a sequence of rectangles. An update represents a transition from one available frame cache state to another, so it's somewhat similar to the video's hardwood. Although the update of the rectangle is generally separate, it is not necessary.
The update part of the display protocol is driven by the client by command. That is, the update occurs only when the server side responds to requests from the client. This lets the protocol update quality be variable. The slower the client/network, the slower the update speed. For some applications, updates for the same area are continuous. If you use a slow client, the cached state of the frame cache can be ignored. This can also reduce the client network speed and drawing speed requirements.
The input protocol is a connection agreement based on a standard workstation keyboard and mouse device.
The input event is sent to the server side by sending the input from the client.
These input events can also be synthesized through non-standard I/O devices.
For example, the stylus engine might produce a keyboard event.
The initial interaction involves the coordination of the transmission of pixel data formats and encoding patterns between the RfB client and the server. This coordination is designed to make the client's work as simple as possible. The bottom line of the design is that the server must provide pixel data in the format required by the client. If the client can handle multiple data formats or coded formats in the same way, it typically chooses the server-side format that is easily generated.
The pixel format involves using pixel values to reproduce different colors. The most commonly used pixel format is 24-bit or 16-bit "True Color", which uses a bit to directly achieve the pixel value to the red, green, blue brightness conversion. A 8-bit "color map" can convert any pixel value to RGB brightness.
Encoding refers to how a rectangle's pixel data is transmitted over a network cable. The rectangle for each pixel data is given a header, the x, y coordinates, the width and height of the rectangle on the screen, and the specified encoding type. Then the data itself uses this particular coding method.
The data itself follows a specific encoding. The current coding methods are raw, Copyrect, Rre, Hextile and Zrle. In practical applications we generally use Zrle, Hextile, and Copyrect, because they provide the best compression for a typical desktop. Other possible encodings include JPEG for static pictures and MPEG for active image transmission.
Protocols can be extended by adding new coding methods.
Protocols can be extended in the following ways:
The new encoding method
A new protocol can be added to the existing client and server side in a compatible and relevant way. Because existing servers will ignore new encodings that they do not support. So the client makes a request with a new encoding and there is no result return.
Pseudo-Encoding method
In addition to the true encoding, the client can request a "pseudo-coded" notification server, which supports an extension of a protocol. If this extension is not supported by the server, it will be ignored. It is worth noting that the client must first assume that the server side does not support this extension until it obtains confirmation of server-side support.
New security approach
Adding a new security approach offers unlimited flexibility by modifying some of the protocol's behavior, but not at the expense of existing client and server-side compatibility. The client and server side can communicate in a good secure way, and certainly not necessarily similar to the RfB protocol.
You should not use a different version number anyway.
The version of the RfB agreement was developed by the RealVNC company. If you use a different protocol version that may not be compatible with RFB/VNC, please contact RealVNC company to ensure compatibility of the protocol. This reduces the conflict between the encoding and the security type.
The RFB protocol can be reliably transmitted, such as byte throttling or message based. As with most protocols, it is also connected through a TCP/IP protocol cluster. The protocol completes the connection by three steps. The first is the handshake message, the purpose of which is to negotiate protocol version and encryption mode. The second step is to initialize the message, primarily for client and server initialization messages. Finally, the interaction of the normal protocol, the client can send the message on demand, and then can get the server's reply.
All messages start with the message type, followed by the specific message data.
The basic types of protocol message descriptions are: U8, U16, U32, S8, S16, and S32.
U represents an unsigned integer, and S represents a signed integer.
All byte integers (except pixel values themselves) conform to the big endian order.
The big endian or little endian are related to the CPU, which affects the order in which integers are sorted in memory. Big endian is high byte in front, little endian is low byte in front, network byte order is generally big-endian.
Pixel represents a pixel value of bytesperpixel bytes, 8XbytesPerPixel = Bits-per-pixel.
1, VNC server sent to support the highest RFB protocol version number to the client, such as: "RFB 003.006/n", that is, version number 3.6, version number fixed format for xxx.xxx, insufficient part of the front to fill 0.
2, the client reply will use the version number, format as above. The client's version number must be less than or equal to the server version number. This allows the server to achieve backward compatibility.
3, the current release of the protocol version is mainly 3.3, 3.7, 3.8 (3.5 version is reported to have problems), the highest version number is 4.0.
(i) v3.7 above version security type
List of supported security types that the server sends
If a client can support a security type on a server, the client sends a byte to confirm the connection
Type of security:
If the number of security types is 0, the connection fails (for example, the server does not support the client request version number), so
There will be a string to describe the reason for the failure:
After the server sends the reason string, it closes the connection.
(ii) The following version of 3.7 (VNC certification as an example)
1. The server sends an unsigned 32-bit integer identifying a security type (related to authentication).
Security Type:
Other authentication types:
Description
①0, the connection fails (for example, the server does not support the client request version number), so there is a string to describe the reason for the failure:
The server closes the connection after the reason-string is sent.
②none, do not need authentication (do not lose password), protocol data will be sent in clear text.
V3.8 the above version and will also have a message with security results.
The V3.3 and 3.7 protocols go directly to the initial message.
③VNC authentication, protocol data will be sent in clear text, the server sent a 16-byte random number.
The client uses DES to encrypt the authentication, using the user's password as the key, and returning the 16-byte reply to the server.
Then comes the security results message.
2, the server sent 16-bit random number.
3. The client uses DES to encrypt the authentication, using the user password as the key, and returning the encrypted 16 bytes to the server.
4, the server to confirm the security authentication, the return value is unsigned 32-bit integer, if 0 is successful, 1 indicates failure. If it is unsuccessful, the server closes the connection directly.
V3.8 if the above version is unsuccessful, there will be a string that describes the cause of the failure and closes the connection.
For V3.8 below, if unsuccessful, the server closes the connection directly.
1, the client sends a byte initialization message.
If you allow other clients on the server to continue connecting, the share flag should be non-0 (true). Otherwise, the server will
Disconnect from other customers.
2, the server sends the initialization message, mainly tells the client server frame cache high, wide, the pixel format and the desktop related name.
This is related to implementation, some implementations are to send 24 bytes first, and then send the desktop name string. Name string format such as: Sh-yinghua-1 (192.168.70.69).
Frame cache width is generally the size of the horizontal resolution, frame cache height is generally the size of the vertical resolution, such as 1024x768.
The pixel format mainly includes the following paragraphs:
The server pixel defines the original pixel format of the server, and this pixel format is used until the client makes
Requests another pixel format with a pixel format message. Bits-per-pixel is the number of digits that are required for each pixel value. This number must be greater than or equal to depth, and depth is used to represent the number of digits useful in pixel values. Current bits per pixel must be 8,16 or 32--less than 8 pixels are not supported. If multibyte pixels are considered big-endian, then the Big-endian flag is Non-zero. Of course, this has no meaning for 8 bits per pixel.
If the true Color label is Non-zero, then the last 6 rules how to determine the brightness of red, green, and blue according to pixel values. Red the most
The large value is the maximum red value (=2 ^n-1, n represents the number of digits used in red). Note that this value is generally in big endian
In the order. Red-replaces the number of replacements that are required to get the least obvious bit. Green Max, green-replace and blue Max, blue-replace and red are similar. To find a red value between the 0-red maximum value, follow these steps:
• Follow the Big-endian flag for pixel values. (For example: If the Big-endian flag is 0, the host's byte order is big endian and then swapped).
• Replace the right with red-replace.
• And red maximum values are logically associated with (in host byte order).
If the true color flag is zero, then the server uses the pixel value is not directly composed of red, green, blue brightness, but
The service is indexed to the color map. Items in a color map are set by the server using the Set Color panel entry (fixcolourmapentries) message.
Note: The bit/pixel is typically the number of color-quality digits set for the display.
None of the current servers can support fixcolourmapentries messages, and only X-based servers can support color mapping. In fact, in order to fully support color mapping, the client probably needs to be able to specify specific pixel values that the server will not use. This may be added to the future protocol version.
All client to server messages the first byte is the message type, and the data type U8.
The client to server message is defined in this article as follows:
The remaining registered message types are:
It is worth noting that if you want to send a message that is not defined in this article, you must obtain a message acknowledgement on the server side.
Set pixel format message
What format pixel values are set in the frame cache update message.
If the client does not send a format pixel message, the pixel value sent by the server follows the pixel format included in the server initialization message.
If the true color flag is zero, it means using the color panel, as long as the client sends a blank message to the color panel, or the panel item is set by the server side, the server can use the Settings color Panel item for the Color panel settings.
Note: The pixel format is described above.
Set encoding format
You can set the encoding to determine the type of pixel data that the server sends. The order in which the messages are encoded is the client
Ranked by priority (the first one has the highest priority). The server may choose this order, or it may not select it.
Pixel data can also be used "raw encoding" if not specified.
In addition to the basic encoding, a client can request a "pseudo-coded" notification server that supports an extended protocol. If the server does not support this extension, it ignores this pseudo encoding. Note: This means that the client assumes that the server does not support its extension until it has been confirmed by the server.
The next step is to encode a number of duplicate encoding types
The encoding format is determined by the encoding type.
Request Frame Cache Update
Notifies the server that the customer is interested in a region in the frame buffer that is qualified by several parameters, such as x-coordinate, y-coordinate, width, and height.
The server usually responds to framebufferupdaterequest messages by sending a framebufferupdate message.
Note that you can send a framebufferupdate message to reply to several framebufferupdaterequest messages.
The server assumes that the customer retains a copy of all the parts of the frame server that it is interested in. This means that the server usually only needs to send an incremental portion of the update to the customer.
However, if, for some reason, the customer loses the content of a particular area it needs, it sends a framebufferupdaterequest message, placing the incremental in the message to 0 (false). This requires the server to send the entire contents of the specified area as quickly as possible. Updates for this area will not be encoded using the copy rectangle.
If the customer does not lose any content in the area of interest, send a framebufferupdaterequest message that sets the incremental in the message to 0 (true). When the specified range in the frame buffer changes, the server sends a framebufferupdate message.
Note that there may be an indeterminate length of interval between Framebufferupdaterequest and Framebufferupdate.
For fast customers, it may want to send incremental framebufferupdaterequests messages at fixed frequencies to avoid consuming network resources.
The increment flag is 0 o'clock, indicating that the full content must be sent over. Key Events
Press and release of a key. If a key is pressed, the flag is Non-zero. When released, it becomes 0.
The key itself is assigned "Keysym" in the X Window system.
For most keys, the "Keysym" corresponds to the ASCII code, referring specifically to the "the Xlib referencemanual" or reference. On Linux for/usr/include/x11/keysymdef.h.
For most common keys, the values for "Keysym" and ASCII code are the same (the first 3 bytes is 0, and the last byte is ASCII). The other command keys are:
Mouse (pointer) event
Detects the movement of a pointer or the press or release of a key. The pointer is currently in (x-coordinate, y-coordinate), the keys of the mouse button are identified with 1 to 8 bitmask, 0 is loosened, and 1 is pressed.
Take the ordinary mouse to say, all zero means the mouse moves, the first 1,2,3 corresponds to the left, the middle, the right key respectively. For the pulley mouse, the wheel corresponds to the 4th position upward, and the scroll wheel corresponds to the 5th position.
The drag operation is the constant sending of the left button pressed message, and the transformation of the mouse coordinates.
Client Text cut
The client has a new iso8859-1 (Latin-1) text in its clipping cache, and the end of the line is represented by a new line character (value 10). No carriage return is required (value is 13). A method for transmitting a Latin-1 character set has not been found yet.
The server to customer message is defined in this article as follows:
The remaining registered message types:
Note Before the server sends a message, it must confirm that the client supports related extensions, usually in the request for "pseudo-encoded"
Time to use. Frame Cache Update
Frame cache updates are composed of a series of pixel data rectangles that are fed into its frame cache by the client.
This is the response to the client frame cache update request. There is a possibility of an indeterminate period between the request and the response.
With the number of pixel data rectangles, each rectangle includes the following:
The following is a specific encoded data. Set color panel entries
When the pixel format uses the color panel, the message tells the client how pixel values are mapped to RGB brightness.
The following is the repetition of specific colors
Currently, there is little or no support for color mapping. Some preliminary work has been done in this area, but it has not been completed yet.
at present, only based on X the server can fully support color mapping. Bells
If there is a bell event, the bell is on the client.
Server Cut Text
If the server's clipboard has new content, the server actively sends the message to the client
The encoding type of this article
Other encoding types
RAW encoding )
That is, the original pixel data is used without any processing. In this case, the data is composed of n pixel values for a rectangle with a width multiplied by the height (that is, the area), which represents each pixel arranged from left to right in the order of the scan line. Obviously, this encoding is the simplest and the least efficient.
RFB requires all customers to be able to handle this raw encoded data, and the RfB server generates the original encoding by default when the customer does not specifically specify that some encoding is required.
Copyrect code )
The Copyrect encoding method is very simple and effective for the client when it has the same pixel data. This encoding mode is represented by x,y coordinates in the network. Let the client know to copy the pixel data for that rectangle. It can be applied in a variety of situations. The most obvious is when the user moves a window on the screen, and when the contents of the window scroll. When optimizing a Picture it is not obvious that a smarter server may only be sent once, because it knows that it already exists in the client's frame cache.
Copying a rectangular encoding is not completely independent of all data rectangles, but for a set of rectangles with exactly the same pixel values, sending only the first rectangle all the data, and then the rectangle only needs to send the upper-left x, y coordinates. In fact, copying a rectangular encoding mainly refers to the sequence of x and y coordinates that follows, and there is no limit to what type of encoding the first rectangle will have, just the position of the first rectangle in the frame buffer to complete the copy operation. Therefore, it is often used to combine the copy rectangle encoding with other encoding types for a particular rectangle.
Next, use the Copyrect encoding to send the same pattern.
Rise-and-run-length,rre)
Rre represents the elevation and run length, as its name implies, which essentially represents the running length encoding of a two-dimensional vector. Rre the rectangle into a format that can be translated by the client's graphics engine. Rre are not suitable for complex desktops, but are useful in some cases.
Rre's idea is to divide the pixel-rectangular data into sub regions, and some units that compress the original region. The best partitioning method in the recent past is generally relatively easy to compute.
Encoding is made up of pixel values, Vb (which is basically the most commonly used pixel value in the rectangle) and a count of N, followed by a list of the sub rectangles of N, which are composed of arrays, (x,y) are the coordinates of the corresponding child rectangles, representing the coordinate values on the left side of the child rectangle (w,h), which indicates the width of the child rectangle. The client can draw using the background pixel data value, and then draw the original rectangle based on the child rectangle.
Two-dimensional stroke coding is essentially a two-dimensional simulation of stroke coding, and its compressibility can be guaranteed to be the same as the stroke code or even better. More importantly, the RRE-encoded rectangle is delivered to the client and can be restored immediately and efficiently by the simplest graphics engine.
In transport, the data is described with the following header:
followed by the repeating sub-rectangle structure:
Coding
Corre is a variant of rre, which restricts the maximum number of rectangles sent to 255x255 pixels, and can represent the dimensions of a child rectangle with one byte. If the server wants to send a rectangle beyond the limit, just divide it into a few smaller RfB rectangles. "For the usual desktop, this way has a better compression than rre."
in fact, if you further limit the size of the rectangle, you can get the best compression degree. "The smaller the maximum size of the rectangle, the better the size of the decision." However, if the maximum limit of the rectangle is too small, it increases the number of rectangles, and because each RFB rectangle has a certain cost, the result will make the compression degree worse. So you should choose a more appropriate number. In the current implementation, the maximum value used is 48x48. Coding
The Hextile is a variant of the RRE encoding, and the rectangle is segmented into 16x16 small pieces, allowing the dimensions of each slice to be 4 bits,
Total 16 digits.
Dividing the original rectangle into small pieces is predefined, meaning that the position and size of each block need not be specified explicitly.
Rectangles are segmented from top to bottom, adhering to the order from left to right, Top-down. The encoded content of the small piece is encoded in a predetermined order. If the width of the entire rectangle is not an integer multiple of 16, then the last small slice of each row is reduced accordingly. Height is similar.
Each slice can be encoded using raw code, or it can be a variant of the RRE encoding, with one type of byte to be described. Each piece has a background pixel value. However, if the background pixel value of the slice is the same as the previous one, then there is no need to define it explicitly. If the child rectangle of the slice has the same pixel value, the foreground pixel value can be defined only once. As with the background pixel value, the foreground pixel value can also be obtained from the previous piece.
So the data made up of small pieces is encoded in sequence. Each small slice begins with a byte of the substring type. It is a mask consisting of bits.
If the raw bit is set, then the rest of the bits are invalid, and then the width x high pixel value (width and height is the width of the small piece).
High). Otherwise the other bits will work.
Background definition-If set, then the pixel value follows the background color of the small slice:
The first non raw slice in the rectangle must set this bit, if not set, then its background will be
A piece of the same.
Foreground definition-If set, the pixel value defines the foreground color of all the child rectangles in the small slice.
If this bit is set, the child rectangle shader bit must be 0.
Any child rectangle-if set, then a byte contains the number of child rectangles.
If this bit is not set, then there will be no child rectangles. (For example, the whole piece is the background color)
Child Rectangle Coloring-If set, the pixel values of any of the rectangles have precedence over the color definition of the child rectangle,
So the child rectangles are:
If you do not, all the child rectangles are the colors of the foreground color, and if the foreground definition is not set, the foreground color and
The same as the previous slice. The Child rectangle is:
The position and size of each child rectangle are defined using two-bit, x-and-y-position and width-
And-height. The most important four-bit x-an d-y-posi tion defines the position of x, and the unimportant definition of Y position. Most
important four-bit width-and-height definition width-1, unimportant definition height-1. Coding
Zrle (Zlib run-length Encoding), which combines Zlib compression, slice technology, palette and run length
Coding. In transit, the rectangle begins with a 4-byte length area followed by zlib compressed data, a single
The zlib "Stream" object is used on the connection of the RfB protocol, so the Zrle rectangle must be encoded in a strict order and
Decoding.
Zlibdata, which represents the order of 64x64 pixels from left to right, from highest to lowest, before compression.
Slice, and Hextile code is a bit like that. If the width of the entire rectangle is not an integer multiple of 64, then the end of each row
Small slices are also reduced accordingly. Height is similar.
The Zrle encoding utilizes a new compressed pixel cpixel (compres se d PIXEL). This and pixel have
The same pixel format, in addition to the true color mark is Non-zero, bit per pixel is 32, color depth is not greater than 24. All the bits make up red,
The brightness of green and blue fills the least important or most important three bytes. If the Cpixel is only 3 bytes long, and contains a
The least important or most important 3 bytes appropriate. So Bytespercpixel is the number of bytes cpixel.
Each slice starts with a substring of bytes, and if the slice is encoded using the run length, then the highest bit of the byte
will be set. The remaining 7 digits represent the drawing style-0 means no style, 1 is monochrome, and 2-127 corresponds
The style. The possible child encoding values are as follows:
0-raw pixel data width x high pixel value (width and height for the corresponding slice width and height, the corresponding pixel value is as follows:
2-16-packaged style type. The corresponding pixel value is the pixel value of the palet tesize (= substring), and the group of pixel values is packaged
Into, each packaged pixel value is represented as a region obeys the style index (0 represents the first entry), corresponding
Palet tesize 2, 1 bits are used, palet tesize 3,4 two are used, from 5-16 have 4-bit area is
Use. Bits are packaged into bytes, and the most important bits represent the leftmost pixels. Because the slice is not 8,4,2 pixel wide.
Product, so the padding bits are used to arrange each row by byte number.
M represents the number of bytes packed in pixels. For Palet Tesize 2 is floor ((width + 7)/8) x Height,
The corresponding 3,4 is floor ((width + 3)/4) x Height, and 5-16 is floor ((width + 1)/2) x
Height
17-127 not used (no advantage for Palet te Rle).
128-Simple RLE It consists of a number of repetitive executions that continue until the end of the piece. Execution may start at the end of a line and the other line. Each run is represented by a pixel value and the length of the pixel value. The length is typically 1 or more bytes. Calculated more than all byte sum + 1 as length. The last byte is implied except for 255 of any byte value. For example, length 1 is expressed as [0],255 represented as [254],256 as [255,0],257] as [255,1],510 representation as [255,254],511], and so on.
129-Not used
130-255 color RLE. The palette is followed by the palet tesize = (subencoding-128) pixel value:
Next, it is similar to the simple rle, with some repetitive execution components, until the end of the slice. Execution length through
Palette index to represent.
If the execution length uses more than one to represent the palette index, and the highest bit is set. Then there is the execution length.
pointer/ Mouse pseudo-encoding
If the client requests a pointer/mouse pseudo encoding, it is capable of drawing the mouse locally. This can significantly improve transmission performance. The server sets the shape of the mouse as part of the update by sending a pseudo rectangle with pseudo mouse encoding. The X and y of the pseudo rectangle represent the hotspot of the mouse, and the width and height indicate the width and height of the mouse in pixels. Data that contains a wide x high pixel value has a bitmask. The bitmask consists of a scan line from left to right, from top to bottom, and each scan line is filled with floor (width +7)/8). The most important bits for each byte represent the leftmost pixel, and the corresponding 1-bit pixels that represent the corresponding pointer are correct.
Desktop size pseudo-encoding
If the client requests a desktop size pseudo encoding, it means that it can handle changes in the frame cache width/height. The server completes an update by sending a pseudo rectangle with the size of the desktop as the previous rectangle. The X and y of the pseudo rectangle are ignored, while the width and height represent the new width and height of the frame cache. No other data is associated with a pseudo rectangle.
The RFB (remote frame buffer) protocol used by RealVNC VNC Server allows the client to negotiate the appropriate authentication method with the server, and there are design errors in the implementation of the Protocol, and remote attackers can bypass the authentication without password to achieve access to the servers.
Specific operational details are as follows:
1 service-side sends its version "RFB 003.008/n"
2 The client replies to its version "RFB 003.008/n"
3 The server sends 1 bytes, equal to the number of security types provided
3a Server-side send byte array description of the type of security provided
4 Client reply 1 bytes, select Security type from 3a array
5 shake hands if necessary, then "0000" on the service side
The RealVNC 4.1.1 or previous version did not check to see if the bytes sent by the client in the 4th step above were provided in the 3a step of the implementation of the RfB 003.008 protocol, so the authentication was transferred from the server side to the client. An attacker could force the client to request "type 1-none" to be a security type and access the server without a password field.
Hazard: Remote attackers can bypass authentication without a password to achieve access to the server.
Workaround: Check that the security type requested by the client is one of the types supported by the server, otherwise disconnect, or prohibit authentication-free security types.
--------------------------------------------------------------------------------------------------------------- ------------------------------------
remotely graphically log on to Linux with VNC (vnc full screen)Original link: http://www.cnblogs.com/cy163/archive/2007/05/23/757625.html VNC introduction "
Network remote control technology refers to a computer (the main control side) to manage another computer (the controlled end), and when the master is at the control end, just as the user sits in front of the controlled end of the operation, can execute the controlled application, and use the system resources of the controlled end.
VNC (Virtual network Computingis a set of remotely controlled computer software developed by the At&t Laboratory, which uses the GPL-licensed terms and is free for anyone to access the software. The VNC software consists mainly of two parts:VNC Server and VNC viewer. The user is required to install VNC server on the computer that is being managed to perform the VNC viewer control on the control side of the main control.
(in Windows also by a well-known network of remote control software ――symantec company launched the pcanywhere.
VNC Server and VNC Viewer support a variety of operating systems, such as the Unix family (Unix,linux,solaris, etc.), Windows and MacOS, so that VNC server and VNC Viewer is installed separately in different operating systems for control. If the current operating master computer does not have the VNC viewer installed, it is possible to control the managed side through a typical web browser.
The workflow for the entire VNC operation is as follows:
(1) VNC client connects to VNC Server via browser or VNC viewer.
(2) VNC server transmits a conversation window to the client, requires a connection password, and an Access VNC server display device.
(3) After the client enters the online password, VNC server verifies that the client has access rights.
(4) If the client is authenticated by VNC server, the client requires VNC server to display the desktop environment.
(5) VNC server, through x Protocol, requires x server to display control over the screen to VNC server for responsibility.
(6) VNC server will be sent to the client by using VNC Communication protocol in the desktop environment of X server, and allow clients to control the desktop environment and input device of VNC server.
"The installation and use of VNC"
My operating environment: controlled by the end of the Redhat8.0, the main control side of Windows XP.
1. Load VNC server with VNC Viewer.
VNC Server Download Address: H
