08-16-2017, 10:31 PM
[attachment=2454]
REMOTE DESKTOP CONTROLLER
By
Rajeev Kumar N Renjith A M Mohanachandran A
CHAPTER 1: INTRODUCTION
Remote Desktop Controller is a client/server software package allowing remote network access to graphical desktop. This software enables you to get a view of the remote machine desktop and thus control it with your local mouse and keyboard. It can be used to perform remote system control and administration tasks in Unix, Windows and other assorted network environments.
This software requires a TCP/IP connection between the server and the viewer, which works on LANs. Each computer has a unique IP address and may also have a name in the DNS. User will need to know the IP address or name of the server when a viewer wants to connect to it. The initial handshaking consists of Client Initialization and Server Initialization messages When the connection between a client and a server is first established, the server begins by requesting authentication from the client using a challenge-response scheme, which typically results in the user being prompted for a password at the client end. The server and client then exchange messages to negotiate desktop size and pixel format to be used.
The server is designed to make the client as simple as possible, so it is usually up to the server to perform any necessary translations. For example, the server must provide pixel data in the format the client wants. Each desktop is like a virtual X display, with a root window on which several X applications can be displayed. Servers mirror the real display to a remote client, which means that the server is not 'multi-user'. It does, however, provide the primary user of a PC with remote access to their desktop. The server processing includes retrieving the pixel information and sending it.
The input side is based on a standard workstation model of a keyboard, and multi-button pointing device. Input events are sent to the server by the client whenever the user presses a key or whenever the mouse is moved. It also requests for all the possible specific parameters that the server can handle, for instance the color mode, pointer events and so on.
CHAPTER 2: PROBLEM DESCRIPTION
2.1 EXISTING SYSTEM
Ample options are there in now a day s operating systems it to execute applications at the remote end. The basic services used by these operating systems today promote executions of the applications at the remote end with just restricted access.
2.2 PROBLEMS WITH THE EXISTING SYSTEM
> Administrator is not having full control
> There is no provision to reboot or shutdown
> Supports only one remote command on the remote machine at the same time
> Never gets the feeling that we are using the remote machine
> We cannot capture the remote systems Desktop
2.3 ADVANTAGES AND DISADVANTAGES OF THE EXISTING SYSTEM
Utilities like Telnet and remote control programs like Symantec's PC anywhere let you execute programs on remote systems, but they can be a pain to set up and require that you install client software on the remote systems that you wish to access. By using this users can save time by accessing data from remote systems. But using this all the users are not able to access the desktop of the remote machine The user will never get the feeling that they are working in the remote machine. Other problems are- Administrator is not having full control over the systems in the LAN. There is no provision to shutdown or reboot remote system. There is no way to use the processor of the remote machine directly
CHAPTER 3: BACKGROUND THEORY
3.1 LITERATURE SURVEY
3.1.1 Protocols used
Proposed system demands use of both User datagram Protocol (UDP) and Transmission Control Protocol (TCP/IP). The listing of available servers at the client side is implemented purely based on the concept of broadcasting packets to all the systems in the network. Selection of this protocol for implementing this feature is due to the need for connectionless protocol.
Datagram service is really the flip side of the session service. It provides a connectionless service for sending packets to a specific host or group of hosts with a workgroup (unicast or multicast) or sending to all hosts in a logical subnet or NetBios scope (broadcast). The datagram service allows for things such as locating the current browse master for a work group or domain by multicasting the request to the work group name.
The desktop controlling section of the software relies on TCP/IP as it requires a dedicated client - server relationship. TCP is a higher level protocol that manages to robustly string together the packets, sorting and retransmitting them as necessary to reliably transmit the data.
3.1.2 Networking Basics
A protocol defines the "rule of the road" that each computer must follow so that all of the systems in the network can exchange data. Computers running on the internet communicate to each other using either the Transmission Control Protocol (TCP) or the User Datagram Protocol (UDP), as the diagram illustrates.
Application(HTTP,FTP .Telnet)
Transport(TCP.UDP)
Network(IP,
Link(device driver,..)
When we write Java programs that communicate over the network, we are actually programming the application layer. Here we can use the classes in the java.net package. These classes provide system independent network communication.
3.1.3 TCP
Definition : TCP (Transmission Control Protocol) is a connection based protocol that provides a' reliable flow of data between two computers.
When two applications want to communicate to each other reliably, they connect and send data back and forth over that connection. This is analogous to making a telephone call. A connection is established when you dial a phone number listener answers. You send data back and forth over the connection by speaking to one another over the phone lines. Like the phone company, TCP guarantees that data sent from one end of the connection actually gets to the other end and in the same order was sent. Otherwise, an error is reported.
TCP provides a point to point channel for applications that require reliable communications. The order in which the data is sent and received over the network is critical to the success of applications like HTTP, FTP and Telnet. When HTTP is used to read from a URL, the data must be received in the order in which it was sent. Otherwise, you end up with a jumbled HTML file, a corrupt zip file, or some other invalid information.
3.1.4 UDP
Definition : UDP (User Datagram Protocol) is a protocol that sends independent packets of data, called datagrams, from one computer to another with no guarantees about arrival. UDP is not connection based like TCP.
The UDP protocol provides for communication that is not guaranteed between two applications on the network. UDP is not guaranteed between two applications on the network. UDP is not connection based like TCP. Rather, it sends independent packets of data, called datagrams, from one application to another. Sending a datagram is much like sending a letter through the postal service: The order of delivery is not important and is not guaranteed each message is independent of any other.
3.1.5 PORTS
Data transmitted over the Internet is accompanied by addressing information that identifies the computer and the port for which it is destined. The computer is identified by its 32-bit IP address, which IP uses to deliver data to the right computer on the network. Ports are identified by a 16 bit number, which TCP and UDP uses to deliver to the right application.
In connection based communication such as TCP, a server application binds a socket to a specific port number. This has the effect of registering the server with the system to receive all data destined for that port. A client can then rendezvous with the server at the servers port, as illustrated here.
p
server o
r
t
client
Definition : The TCP and UDP protocols use ports to map incoming data to a particular process running on a computer.
Port numbers ranges from 0 to 65535 because 16 - bit numbers represent ports. The port numbers ranging from 0 to 1023 are restricted; they are reserved for use by well known services such as HTTP, FTP and other system services. These ports are called well known ports. Our applications should not attempt to bind to them.
In datagram based communications such as UDP, the datagram packets contains the port number of its destination and UDP routes the packet to the appropriate application as illustrated in this figure.
port #
data
3.1.6 Networking Classes in the JDK
Through the classes in "Java.net', Java programs can use TCP or UDP to communicate over the internet. The URL, URLConnection, Socket and ServerSocket classes all use TCP to communicate over the network. The DatagramPacket, DatagramSocket and MulticastSocket classes are for use with UDP.
3.1.7 SOCKET
Definition : A Socket is one end point of a two way communication page link between two programs running on the network. A Socket is bound to a port number so that the TCP layer can identify the application that data is destined to be sent.
A Socket is one end point of a two way communication page link between two programs running on the network. Socket classes are used to represent the connection between a client program and a server program. Java.net package
provides two classes, Socket and ServerSocket that implement client side of the connection and the server side of the connection, respectively.
Normally, a server runs on a specific computer and has a socket that is bound to a specific port number. The server just waits, listening to the socket for a client to make a connection request.
On the client side : the client knowns the host name of the machine on which server is running and the port number to which the server is connected. To make a connection request, the client tries to rendezvous with the server on the server machine and port.
server
client
N
connection request
If everything goes well, the server accepts the connection upon acceptance, the server gets a new socket bounds to a different port. It needs a new socket ( and consequently a different port number) so that it can continue to listen to the original socket for connection request while tending to the needs of the connected client.
On the Client side, if the connection is accepted, a socket is successfully created and the client can use the socket to communicate with the server. Note that the socket on the client side is not bound to the port number used to rendezvous with the server. Rather, the client is assigned a port number local to the machine on which the client is running.
Reading from and Writing to a Socket ( for client)
1. Create a Socket
2. Specify the address and service port of the server program
3. Establish connection with the server
4. Send and receive information
5. Close the socket when finished, terminating the conversation
-
Reading from and Writing to a Socket ( for server)
1. Create a Socket
2. Listen for incoming connection from clients
3. Accept the client connection
4. Send and receive information
5. Close the socket when finished, terminating the conversation
3.1.8 DATAGRAMS
Definition : A Datagram is an independent self contained message send on the network whose arrival, arrival time and content are not guaranteed.
Applications that communicate via datagrams send and receive completely independent packets of information. These clients and servers do not have and do not need a dedicated point to point channel. The delivery of datagrams to their destinations is not guaranteed. Nor is the order of their arrival.
Java.net Package contains two classes to help you to write Java programs that use datagrams to send and receive over the network - DatagramSocket, DatagramPacket and MulticastSocket. An application can send and receive DatagramPackets through a DatagramSocket. In addition, DatagramPackets can be broadcast to multiple recipients all listening to a MulticastSockets.
3.1.9 FRAME BUFFER
The portion of memory reserved for holding the complete bit-mapped image that is sent to the monitor. Typically the frame buffer is stored in the memory chips on the video adapter. In some instances, however, the video chipset is integrated into the motherboard design, and the frame buffer is stored in general main memory.
The frame buffer is organized as a single one-dimensional array of pixel values. The first byte (byte 0) of the frame buffer represents the upper left corner pixel of the screen. Byte 1 is immediately to its right. Byte 1279 is the last (right most) displayable pixel on the top line. The next 768 bytes are not displayable. feyte 2048 is the first (left-most) pixel on the second line from the top. The last
(lower right corner) pixel on the screen is byte number 2,096,383 (1023x2048+1279).
3.1.10 VIDEO MEMORY
The memory in a computer's graphics adaptor, used to store the image displayed on a bitmap display. Often this is built using VRAM chips. There is normally a simple correspondence between groups of bits in video memory and the dots or "pixels" on the screen, such that writing to a given group of bits will alter the appearance of a single dot. If each pixel corresponds to eight bits then it can have any of 256 colours.
The video display electronics is responsible for reading the data from video memory and converting it into the necessary signals to drive the display. Often this includes a colour palette which converts pixel values into RGB triplets.
3.1.11 COLOUR PALETTE
j Colour palette is a device which converts the logical colour numbers stored in each pixel of video memory into physical colours, normally represented as RGB triplets, that can be displayed on the monitor. The palette is simply a block of fast RAM which is addressed by the logical colour and whose output is split into the red, green and blue levels which drive the actual display (e.g. CRT).
The number of entries (logical colours) in the palette is the total number of fcolours which can appear on screen simultaneously. The width of each entry determines the number of colours which the palette can be set to produce.
A common example would be a palette of 256 colours (i.e. addressed by .eight-bit pixel values) where each colour can be chosen from a total of 16.7 million colours (i.e. eight bits output for each of red, green and blue).
TT
Changes to the palette affect the whole screen at once and can be used to produce special effects which would be much slower to produce by updating pixels
3.1.12 BITS PER PIXEL
The number of bits of information stored per pixel of an image or displayed by a graphics adapter. The more bits there are, the more colours can be represented, but the more memory is required to store or display the image.
A colour can be described by the intensities of red, green and blue (RGB) components. Allowing 8 bits (1 byte) per component (24 bits per pixel) gives 256 levels for each component and over 16 million different colours - more than the human eye can distinguish. Microsoft Windows alls this truecolour. An image of 1024x768 with 24 bpp requires over 2 MB of memory. "High colour" uses 16 bpp (or 15 bpp), 5 bits for blue, 5 bits for red and 6 bits for green. This reduced colour precision gives a slight loss of image quality at a 1/3 saving on memory.
Standard VGA uses a palette of 16 colours (4 bpp), each colour in the palette is 24 bit. Standard SVGA uses a palette of 256 colours (8 bpp). Some graphics hardware and software support 32-bit colour depths, including an 8-bit "alpha channel" for transparency effects.
3.1.13 HOOKS
In the Microsoft Windows operating system, a hook is a mechanism by iwhich a function can intercept events (messages, mouse actions, keystrokes) before they reach an application. The function can act on events and, in some cases, modify or discard them. Functions that receive events are called filter functions and are classified according to the type of event they intercept. For example, a filter function might want to receive all keyboard or mouse events. For Windows to call a filter function, the filter function must be installed that is, attached to a Windows hook (for example, to a keyboard hook). Attaching one or more filter functions to a hook is known as setting a hook. If a hook has more than one filter function attached, Windows maintains a chain of filter functions. The most recently installed function is at the beginning of the chain, and the least recently installed function is at the end.
When a hook has one or more filter functions attached and an event occurs that triggers the hook, Windows calls the first filter function in the filter function chain. This action is known as calling the hook. For example, if a filter function is attached to the CBT hook and an event that triggers the hook occurs (for example, a window is about to be created), Windows calls the CBT hook by calling the first function in the filter function chain.
To maintain and access filter functions, applications use the SetWindowsHookEx and the UnhookWindowsHookEx functions.
Hooks provide powerful capabilities for Windows-based applications. These applications can use hooks to:
Process or modify all messages meant for alJ the dialog boxes, message boxes, scroll bars, or menus for an application (WHMSGFILTER).
Process or modify all messages meant for all the dialog boxes, message boxes, scroll bars, or menus for the system (WHSYSMSGFILTER).
Process or modify all messages (of any type) for the system whenever a GetMessage or a PeekMessage function is called
(WH_GETMESSAGE).
Process or modify all messages (of any type) whenever a SendMessage function is called (WH_CALLWNDPROC).
Record or play back keyboard and mouse events (WH_JOURNALRECORD, WH_JOURNALPLAYBACK).
Process, modify, or remove keyboard events (WH_KEYBOARD).
Process, modify, or discard mouse events (WHMOUSE).
Respond to certain system actions, making it possible to develop
computer-based training (CBT) for applications (WHCBT).
Prevent another filter from being called (WH_DEBUG). Applications have used hooks to:
Provide F1 help key support to menus, dialog boxes, and message boxes (WHJVISGFILTER).
Provide mouse and keystroke record and playback features, often referred to as macros. For example, the Windows Recorder accessory program uses hooks to supply record and playback functionality (WH_JOURNALRECORD, WH_JOURNALPLAYBACK).
Monitor messages to determine which messages are being sent to a particular window or which actions a message generates (WHGETMESSAGE, WH_CALLWNDPROC). The Spy utility program
in the Platform SDK uses hooks to perform these tasks. The source for Spy is available in the SDK.
Simulate mouse and keyboard input (WH_JOURNALPLAYBACK). Hooks f provide the only reliable way to simulate these activities. If you try to
simulate these events by sending or posting messages, Windows internals do not update the keyboard or mouse state, which can lead to
unexpected behavior. If hooks are used to play back keyboard or mouse events, these events are processed exactly like real keyboard or
mouse events. Microsoft Excel uses hooks to implement its
SEND.KEYS macro function.
. Provide CBT for applications that run in the Windows environment (WH_CBT). The WH_CBT hook makes developing CBT applications much easier.
3.1.14 Remote Frame Buffer
Remote Frame Buffer is a simple protocol for remote access to graphical user interfaces. Because it works at the frame buffer level it is applicable to all windowing systems and applications, including X11, Windows and Macintosh. The remote endpoint where the user sits (i.e. the display plus keyboard and/or pointer) is called the RFB client. The endpoint where changes to the frame buffer originate (i.e. the windowing system and applications) is known as the RFB server.
! RFB is truly a "thin client" protocol. The emphasis in the design of the RFB protocol is to make very few requirements of the client. In this way, clients can run on the widest range of hardware, and the task of implementing a client are made as simple as possible.
i The protocol also makes the client stateless. If a client disconnects from a given server and subsequently reconnects to that same server, the state of the user interface is preserved.
I Furthermore, a different client endpoint can be used to connect to the same RFB server. At the new endpoint, the user will see exactly the same graphical user interface as at the original endpoint. In effect, the interface to the user's applications becomes completely mobile. Wherever suitable network connectivity exists, the user can access their own personal applications, and the
T5
state of these applications is preserved between accesses from different locations.
Protocol Version: Handshaking begins by the server sending the client a
ProtocolVersion message. This lets the client know which is the highest RFB
protocol version number supported by the server. The client then replies with
a similar message giving the version number of the protocol which should
actually be used (which may be different to that quoted by the server). A
client should never request a protocol version higher than that offered by the server. It is intended that both clients and servers may provide some level of backwards compatibility by this mechanism.
Addition of a new encoding or pseudo-encoding type does not usually
require a change in protocol version, since a server can simply ignore
encoding it does not understand.The ProtocolVersion message consists of
12 bytes interpreted as a string of ASCII characters in the format "RFB
xx.yy\n" where xx and yy are the major and minor version numbers,
padded with zeros.
No. iil'hvks Value
12 "RFB 00 J. 0C'j\n" llK 52*> -42 20 30 JO 33 i- JU 30 JKttl
or
No. .ii'byk-s Value
12 "RFB t 03 . c-OJSr." ihcx 5">*42 2D 30 JO.5 2o 30 0 37 UH
or
No. ol'byto Value
12 "RFB DO J. 00*\n (hex 52 46 42 20 30 JO 33 2e J(l U Js ij.il
Client Initialization: Once the client and server are sure that they're ready to talk to
one another using the agreed security type, the client sends an initialization message.
No. ofbjrleg Tyrv V,ilii*] 1 X'f.t. npii"ii
1 ua
Shared-flag is non-zero (true) if the server should try to share the desktop by leaving other clients connected, zero (false) if it should give exclusive access to this client by disconnecting all other clients.
Server Initialization: After receiving the Client Initialization message, the server sends a Server Initialization message. This tells the client the width and height of l! server's frame buffer, its pixel format and the name associated with the desktop:
No. of byles Tjfjk [Value] Description
> 1116 frasnt'fattfcr-H : /:!;
2 IT 16
16 FTXSL_EX>HMA.T irrwr-ptxety'orwat
4 U32
mime-feiiglli tie array titi/xe-strtiig
Vi'hCK PIXEL FORMAT h
No. of bytes 1;. v Viliic 1 X-scripiiun
1 US: i\'is-}jtr-i'ft.el
1 US ifeplfi
1 ' us ttX-eiiltafi-f&ig
1 us true-cntoiir-jkig
2 UlS ii%f-max
2 UlS gnxn-max
UlS Mnt--ma.il1 ua tml-shtjl
] ua gyvt'H-iitft
1 us Nue-sktft
\
Server-pixel-format specifies the server's natural pixel format. This pixel format will be used unless the client requests a different format using the SetPixelFormat message.
Bits-per-pixel is the number of bits used for each pixel value on the wire. This must be greater than or equal to the depth which is the number of useful bits in the pixel value. Currently bits-per-pixel must be 8, 16 or 32 less than 8-bit
pixels are not yet supported. Big-endian-flag is non-zero (true) if multi-byte pixels are interpreted as big endian. Of course this is meaningless for 8 bits-per-pixel.
If true-colour-flag is non-zero (true) then the last six items specify how to extract the red, green and blue intensities from the pixel value. Red-max is the maximum red value (where is the number of bits used for red). Note this value is always in big endian order. Red-shift is the number of shifts needed to get the red value in a pixel to the least significant bit. Green-max, green-shift and blue-max, blue-shift are similar for green and blue. For example, to find the red value (between 0 and red-max) from a given pixel, do the following: Swap the pixel value according to big-endian-flag
(e.g. if big-endian-flag is zero (false) and host byte order is big endian,
then swap).
+ Shift right by red-shift.
+ AND with red-max (in host byte order).
If true-colour-flag is zero (false) then the server uses pixel values which
are not directly composed from the red, green and blue intensities, but
which serve as indices into a colour map. Entries in the colour map are set by the server using the SetColourMapEntries message
Rectangular updates: The display side is based around a single graphics primitive: "put a rectangle of pixel data at a given x,y position". This might seem an inefficient way of drawing arbitrary user interface components. But because we have a variety of different encoding schemes for the pixel data, we can select the appropriate scheme for each rectangle we send, and make the most of network bandwidth, client drawing speed and server processing speed.
The lowest common denominator is the so-called raw encoding, where the rectangle is simply pixel data sent in left-to-right scanline order. All clients and servers must support this encoding. However, the encodings actually used on any given VNC connection can be negotiated according to the abilities of the server, the client, and the connection between the two.
The copy rectangle encoding, for example, is very simple and efficient and can be used when the client already has the same pixel data elsewhere in its frame buffer. The server simply sends an X,Y coordinate giving the position from which the client can copy the rectangle of pixel data. This means that operations such as dragging or scrolling a window, which involve substantial changes to the screen, may only require a few bytes. Most clients will support this encoding, since it is generally simple to implement and saves bandwidth.
A typical workstation desktop has large areas of solid colour and of text. Some of our most effective encodings take advantage of this by efficiently describing rectangles consisting of one majority (background) colour and 'sub-rectangles' of different colours. There are numerous other possible schemes. We might use a JPEG encoding for still images or MPEG for efficient transmission of moving images. An encoding which uses some kind of caching of pixel data would be good for rendering text, where the same character is drawn in the same font multiple times. Subsequent occurrences of the same character would be encoded simply by reference to the first occurrence.
Adaptive update protocol: A sequence of these rectangles makes a frame buffer update (or simply update). An update represents a change from one valid frame buffer state to another, so in some ways is similar to a frame of video, but it is usually only a small area of the frame buffer that will be affected by a given update. Each rectangle may be encoded using a different scheme. The server can therefore choose the best encoding for the particular screen content being transmitted and the network bandwidth available.
The update protocol is demand-driven by the client. That is, an update is only sent by the server in response to an explicit request from the client. This gives the protocol an adaptive quality. The slower the client and the network are, the lower the rate of updates becomes. Each update incorporates all the changes to the 'screen' since the last client request. With a slow client and/or network, transient states of the frame buffer are ignored, resulting in reduced network traffic and less drawing for the client. This also improves the apparent response speed.
Pixel format: refers to the representation of individual colours by pixel values. The
most common pixel formats are 24-bit or 16-bit "true colour", where bit-fields within
the pixel value translate directly to red, green and blue intensities, and 8-bit "colour
map" where an arbitrary mapping can be used to translate from pixel values to the
RGB intensities.
Encoding: refers to how a rectangle of pixel data will be sent on the wire. Every
rectangle of pixel data is prefixed by a header giving the X,Y position of the rectangle on the screen, the width and height of the rectangle, and an encoding type which specifies the encoding of the pixel data. The data itself then follows using the specified encoding.
3.2 STATE OF ART
3.2.1 VNC
VNC is a GUI remote access program that allows full console access. It has clients and servers covering much different architecture. It is a thin client
7TT
technology for using an X desktop and it stands for Virtual Network Computing [ and can be thought of as a software version of the "network computer" which never quite took off. User can start a desktop session, disconnect from it and then reconnect to it at will, even from a different X terminal. All of the applications are available exactly as before disconnecting.
In contrast, although X itself allows applications to display remotely, it -does not provide this persistence; users cannot move an application window from one X server to another. Another thing that VNC allows user to do is to have several viewers all watching the same server. This can be useful in training environments.
The original VNC design and reference implementation arose from Olivetti Research Labs in Cambridge where it was used in a "teleport" system, whereby their desktop could follow user around the building, hopping to the nearest convenient terminal (an "active badge" on their clothing made this possible). With X, the server is on the machine in front of user and drives the video card. An X client is an application that wants to display a window on the server, like a web browser or email application. A VNC client, in contrast, is an application that displays the desktop image to the user; normally the job of the X server. Both the VNC server and client perform tasks that the X server would normally do: maintaining the desktop image and displaying that image to the user.
The two independent parts are the client and of course the server and each can be running on a different platform. The protocol is designed to adapt to the amount of bandwidth available. It is also designed to make the client very simple, without requiring extensive computing resources. This makes it ideal for thin client deployments, diskless if need be, and this perhaps is the most convenient form of network computer made from commodity components. VNC is in fact quite pervasive it can run on anything from high end servers to hand held devices such as palm pilots.There is even a VNC viewer written in Java.
This means that user can use it from their web browser on a machine that has had no special set up. Just point the browser at a special port on the server and it will serve up a Java applet ready to go. The port number will be 5800 plus the , display number for the VNC server. The display number is used to identify different VNC servers on the same machine, in exactly the same way as X ' works. In fact, VNC servers and X servers share the same display number range, ! and so if there is already an X server running, a newly started VNC server will get display number 1. To use the Java viewer for that server, point a browser at http://machinename:5801/. Note that the Java applet uses the normal VNC port number. So, if user want to use a VNC server that is behind a firewall, user might want to open up that port.ln Red Hat Linux 7.3 there is a VNC service that can be started on boot-up. This will start VNC servers for a configured list of users, each ; with their own assigned display number. To configure it, user need to edit the file /etc/sysconfig/vncservers and set which users should have VNC servers started for them, and with which display numbers.
Although VNC is the name of the technology as a whole, the protocol it uses is called RFB, which stands for Remote Frame Buffer. Conceptually user can think of a VNC client as a sort of abstracted video card. This video card happens to be over a network and is accessible only via the RFB protocol.Compare this with how X traditionally works: the application may or may not be remote but the X server is running on the machine in front of user, showing user the application's window on their monitor. With VNC there is an paddition: the X'server machine may be different to the one that their monitor is [connected to.The X protocol is itself reasonably low bandwidth but it is difficult to compare it directly to RFB because they are at different levels: where X speaks in terms of lines and text and so on, RFB is only concerned with pixels, and mouse and keyboard events. There is no provision in RFB for storage at the viewer end other than the frame buffer itself, since this makes the viewer a simpler application.
UNIX can have several X servers running at the same time, each with a : different login, and VNC works just as any other X server would. But Windows ! only has one session to use and so on that platform the VNC server attaches to f that. This means that when user start a VNC server on a Windows machine user L are sharing that existing session but on a UNIX machine a new session is started. There are however ways to share an existing session under UNIX, just like with Windows. Both types of sharing are useful in different circumstances. When a VNC viewer first makes a connection to the server, they negotiate common ground for their capabilities. This allows implementations to be extensible to some degree. It is also at this initial stage that any authentication is : performed. It is important to note here that this is only a simple authentication ; scheme to prevent casual misuse and no encryption is used at all in the mainstream version, although some implementations do have ways to do this. From then on it is, perhaps surprisingly, the viewer and not the server that initiates messages. In effect the viewer repeatedly queries the server for any screen changes as well as transmitting input events such as typing. This leads to the bandwidth usage being adaptively self-limiting; the slower the network, the less frequently updates can be requested. With a fast viewer and network, updates for tiny changes will be requested, but if the network is slow then several changes will be combined into one screen update. Commonly the viewer will only ask for updates every few seconds, or when the user moves the mouse or types ion the keyboard. The illusion of constant updates can be maintained by asking ,for more updates when the screen actually does change; the idea is that usually several changes will happen very shortly after one another.
The server and viewer negotiate an encoding to use which they both Understand and the specification lists some common ones. They include "hextile" (which breaks screen areas into tiles), "copyrect" (copying another area of the screen), "ZRLE" (a compressed variant) and "raw" for when the server is the same machine as the client. It turns out to be faster to transfer unencoded screen updates when it is all on the same machine.The RFB protocol can be used in other ways than originally intended as well. One such way is scriptable remote control, which could be used for automating tasks with applications that were not designed with scripting in mind. User can run them in a VNC session and control the session using a program such as 'rfbplaymacro'. This takes a script and
f translates it into RFB input events such as mouse movements, button presses
f and keyboard typing.
Another use of the RFB protocol is session playback, in other words recording a series of screen updates for later display. User might want to do this if user are setting up a "rolling demo" for a shop display. A simple way to achieve this is just to record the RFB screen updates as they happen into a file with a purpose written application. The disadvantage of this approach is that only applications which understand the RFB protocol will be able to interpret the saved screen updates. However there is one utility named vnc2swf which converts this format into ShockWave Flash.VNC is currently going in several directions. The fact that historically the Olivetti/AT&T releases were so slow has led to several independent VNC development efforts springing up. There are two main programs: xOrfbserver and xrfbviewer. The first is an implementation of the VNC server that can make VNC on UNIX act as it does on Windows. The way it works is that it shares their existing X session by watching the screen for updates. It is truly platform-independent. A desktop running on a Linux machine may be displayed on a PC or a Solaris machine or any number of other architectures. The simplicity of the protocol makes it easy to port to new platforms.
VNC alone has some inherent security issues. All communication is in plain text and the authentication scheme is very weak. However, by tunneling VNC over SSH will fix both of these problems. SSH will encrypt all information over the wire and use NT's authentication, which is much stronger than VNC's. 3.2.2 TIGHT VNC
TightVNC is an enhanced version of VNC, which includes a lot of new features, improvements, optimizations and bugfixes over the original VNC
t version. It includes better compression algorithms for improved performance over WAN links, as well as new features like automatic SSH tunneling between
f Unix/Linux hosts. TightVNC can be used to perform remote control and administration tasks in Windows, Unix and mixed network environments. It can
fbe very helpful in distance learning and remote customer support. Finally, you can find a number of additional VNC-compatible utilities and packages that can extend the areas where TightVNC can be helpful. TightVNC is a project
maintained by Constantin Kaplinsky.
TightVNC is fully compatible with the standard RFB protocol used in VNC, so users can use TightVNC viewer with the standard VNC server and vice versa. But the protocol enhancements implemented in TightVNC will work only if these Enhancements are supported on both sides of the connection.
Here is a brief list of TightVNC features:
File transfers in Win32 version: Users can updload files from your local machine to the TightVNC server, and download files from the server to you computer.
1 Local cursor handling: Cursor movements do not generate screen updates any more, remote cursor movements are processed locally by the viewer, so users do not see slow remote cursor movements behind the local cursor.
Efficient compression algorithms: New Tight encoding is optimized for slow and medium-speed connections and thus generates much less traffic
as compared to traditional VNC encodings. At the same time, TightVNC supports all the standard VNC encodings, so it can operate efficiently over fast networks, too. Thus, with TightVNC users can work remotely almost in real time in most network environments.
Configurable compression levels: Users can choose any appropriate level of compromise between compression ratios and coding speed, depending on the connection speed and processor power.
Optional JPEG compression: There is an optional image compression added to the TightVNC, this will compress color-rich screen areas much more efficiently.
. Enhanced Web browser access: TightVNC includes a greatly improved Java viewer with full support for Tight encoding, local cursor feature, 24-bit color mode, and more. The Java viewer applet can be accessed via built-in HTTP server like in the standard VNC.
Support for two passwords (full-control and read-only): The server allows or disallows remote keyboard and mouse events depending on which password was used for authentication.
Advanced Properties dialog in WinVNC: Unlike the standard VNC, TightVNC gives the possibility of setting a number of advanced settings directly from the WinVNC GUI, and to apply changed settings immediately. There is no need to launch regedit to set query options, connection priority, to allow loopback connections, disable HTTP server and so on.
t Flexible configuration options: Unlike the standard VNC, TightVNC allows its users to choose arbitrary port numbers for TCP/IP connections, in addition to display numbers traditionally used in VNC.
Automatic SSH tunneling on Unix: The Unix version of TightVNC viewer can tunnel connections via SSH automatically using a local
: SSH/OpenSSH client installation.
IE
3.2.3 Windows XP Professional REMOTE DESKTOP
With the Remote Desktop feature in Windows XP Professional, users can remotely control their computer from another place. This allows them to use the data, applications, and network resources that are on their office computer, without being in your office.
To use Remote Desktop, you need the following:
Windows XP Professional installed on your office computer, or whichever computer you plan to operate remotely. This computer is known as the host.
A remote computer running Windows 95 or a more recent version of Windows. This computer is known as the client and it must have the Remote Desktop Connection client software installed.
A connection to the Internet. A broadband Internet connection improves performance, but it is not necessary because Remote Desktop transfers only the minimal data (such as display data and keyboard data) to remotely control your host computer. Therefore, even low-bandwidth Internet connections allow you to remotely control your office computer.
Remote Desktop works well even over low-bandwidth Internet connections, because only the keyboard input, mouse input, and display output data are transmitted over the network to your remote location. Remote Desktop is based on the technology behind Terminal Services in Windows NT Server and Windows 2000 Server.
Windows XP Professional adds several capabilities to make Remote [ Desktop useful for your day-to-day computing. These include:
System redirection: Files on the remote computer are accessible through Remote Desktop as if they were on a network-shared drive. You can save a document on your home computer, and then start Remote Desktop and use programs on your office computer to edit that document.
Printer redirection: Users can work remotely with documents on their office computer, and then print the documents at home.
Port redirection: Users can use the devices on their home computer and the applications on office computer together via Remote Desktop.
Audio: Users can run audio-enabled programs on their office computer and hear the sound from speakers on home computer.
Clipboard: The Remote Desktop and the client computer share a clipboard that allows data to be interchanged.
3.2.4 REMOTE COTROL SOFTWARE
. Remote control software provides businesses the ability to login and access computers remotely. Utilizing remote control software enables personnel to transfer files or folders quickly and easily, and communicate by instant message, text chat, or voice intercom from any PC, cell phone, wireless PDA. As with many IT departments having the ability to remotely manage computers, expands the breath of service level and reach that can be provided by a centralized support groups.
Remote control software allows its users to remotely control a computer over any TCP/IP or dial-up connection. Most remote control software emulates
Jhe destination computer to make it look as if they were in front of it. With remote iontrol software, it introduces several features, such as file transfer, video, Jnouse and keyboard emulation, security, and total control just to name a few. With the ability to manage computers remotely, provides the chance of Lnhancing support, response times, and costs to any IT support groups and businesses.
Some of the benefits of Remote control software are: I Reducing the need to travel to provide computer support
Provides quicker response to remote issues
Centralizing and streamlines computer support
Can help in reducing overall costs
Reduce the involvement of end-users to help with support 3.2.5 RADMIN
I Radmin is an award-winning multifunction remote control program. Radmin enables users to remotely monitor or work on one or more network computers right from their own workstation. It is a complete remote control -solution with such features as File Transfer, NT security, Telnet and Multilanguage Support built-in. Users can view the remote computer's screen on their monitor either in a window or full screen. All the mouse movements and keyboard signals are transferred directly to the remote computer. "With Radmin users can work with any remote computer so long as it is connected to the Internet or the local area network. On a LAN, real-time speeds of 100 - 500 screen updates per second are normal. Radmin's speed can be adjusted up or down to save your bandwidth.
Radmin is very easy to learn and use. It is extremely secure, employing 128-bit encryption for all data streams. Radmin utilizes the ever-present TCP/IP
protocol the most widespread protocol used in LANs, WANs and the Internet. This means you can control virtually any computer from anywhere in the world. When in "Full control" mode, you have complete, unlimited control of the remote computer so you can launch applications, work on documents, transfer files, even shut it down. Of course, that is provided you are the system administrator or have been granted these permissions by the system administrator. From the beginning, our goal was to create the most secure remote access utility possible. Our developers were able to achieve this goal as well as boost Radmin's performance right off the charts.
3.2.6 REALVNC
RealVNC software makes it possible to view and fully-interact with one computer from any other computer or mobile device anywhere on the Internet. RealVNC software is cross-platform, allowing remote control between different types of computer. For ultimate simplicity, there is even a Java viewer, so that any desktop can be controlled remotely from within a browser without having to install software.
The RealVNC protocol is a simple protocol for remote access to graphical user interfaces. It is based on the concept of a remote framebuffer or RFB. In the past we have tended to refer to the RealVNC protocol as the RFB protocol, fco you may have seen this term in other publications. The protocol simply allows a server to update the framebuffer displayed on a viewer. Because it works at the framebuffer level it is potentially applicable to all operating systems, windowing systems and applications. This includes X/Unix, Windows, and Macintosh, but might also include PDAs, and indeed any device with some form of communications link. The protocol will operate over any reliable transport such as TCP/IP.
This is truly a "thin-client" protocol: it has been designed to make very few requirements of the viewer. In this way, clients can run on the widest range of hardware, and the task of implementing a client is made as simple as possible. p"he display side of the protocol is based around a single graphics primitive: "put-a rectangle of pixel data at a given x,y position". This might seem an inefficient way of drawing arbitrary user interface components. But because we have a variety of different encoding schemes for the pixel data, we can select the appropriate scheme for each rectangle we send, and make the most of network bandwidth, client drawing speed and server processing speed.
The lowest common denominator is the so-called raw encoding, where the rectangle is simply pixel data sent in left-to-right scanline order. All clients and servers must support this encoding. However, the encodings actually used on !any given RealVNC connection can be negotiated according to the abilities of the server, the client, and the connection between the two.
The copy rectangle encoding, for example, is very simple and efficient and can be used when the client already has the same pixel data elsewhere in its framebuffer. The server simply sends an X,Y coordinate giving the position from jwhich the client can copy the rectangle of pixel data. This means that operations ;such as dragging or scrolling a window, which involve substantial changes to the screen, may only require a few bytes. Most clients will support this encoding, since it is generally simple to implement and saves bandwidth.
A typical workstation desktop has large areas-of solid colour and of text. Some of our most effective encodings take advantage of this by efficiently describing rectangles consisting of one majority (background) colour and 'sub-rectangles' of different colours. There are numerous other possible schemes. We might use a JPEG encoding for still images or MPEG for efficient transmission of moving images. An encoding which uses some kind of caching of pixel data would be good for rendering text, where the same character is drawn
I in the same font multiple times. Subsequent occurrences of the same character would be encoded simply by reference to the first occurrence.
A sequence of these rectangles makes a framebuffer update (or simply I update). An update represents a change from one valid framebuffer state to another, so in some ways is similar to a frame of video, but it is usually only a f small area of the framebuffer that will be affected by a given update. Each ! rectangle may be encoded using a different scheme. The server can therefore
choose the best encoding for the particular screen content being transmitted and
the network bandwidth available.
The update protocol is demand-driven by the client. That is, an update is only sent by the server in response to an explicit request from the client. This gives the protocol an adaptive quality. The slower the client and the network are, the lower the rate of updates becomes. Each update incorporates all the changes to the 'screen' since the last client request. With a slow client and/or network, -transient states of the framebuffer are ignored, resulting in reduced network traffic and less drawing for the client. This also improves the apparent response speed.
The input side of the protocol is based on a standard workstation model of a keyboard and multi-button pointing device. Input events are sent to the server by the client whenever the user presses a key or pointer button, or whenever the pointing device is moved. These input events can also be synthesised from other non-standard I/O devices.
When the connection between a client and a server is first, established, the server begins by requesting authentication from the client using a challenge-response scheme, which typically results in the user being prompted for a password at the client end. The server and client then exchange messages to negotiate desktop size, pixel format, and the encoding schemes to be used. The client then requests an update for the entire screen, and the session begins.
Because of the stateless nature of the client, either side can close the connection at any time without adverse consequences.
RealVNC Clients
It requires only a reliable transport (usually TCP/IP), and a way of displaying pixels (either directly writing to the framebuffer, or going through a windowing system). RealVNC clients exist for all flavours of Unix, Windows, Macintosh, Java and for smaller handeld appliances.
RealVNC Servers
The protocol is designed to make the client as simple as possible, so it is usually up to the server to perform any necessary translations. For example, the server must provide pixel data in the format the client wants. There are servers Unix, Windows and Macintosh platforms A Unix machine can run a number of X servers for different users, each of which represents a distinct RealVNC desktop. Each RealVNC desktop is like a virtual X display, with a root window on which several X applications can be displayed. The Windows server is a little more difficult to create, because there are fewer places to insert hooks into the system to monitor display updates, and a less clearly-defined model of multiuser operation. Servers simply mirror the real display to a remote client, which means *hat the server is not 'multiuser'. It does, however, provide the primary user of a PC with remote access to their desktop.
3.2.7 FIREPASS
F5's FirePass controller enables enterprises to provide secure, reliable and intuitive remote access to corporate applications and data using standard web browser technology, without the headaches associated with time-consuming
client software installation and configuration, or changes to server-side Applications.
FirePass is the first SSL VPN solution with complete cross-platform support. Extending its support for any IP application to Apple Macintosh , PocketPC and Linux clients, in addition to Microsoft Windows , and expanding client and application security for web, email and file application access, FirePass delivers the industry's most ubiquitous solution for secure network access.
It also offers the only open API and SDK that enables 3rd party application vendors to build seamless, secure remote access into their client applications.
Full Network Access
The corporate laptop user, also referred to as a "trusted" user, is an employee using company issued and maintained equipment. The trusted user is typically an executive or a member of the sales team who needs the same access to network resources as users in the office.
For these users, the FirePass controller delivers network access for Windows, Macintosh, PocketPC and Linux systems. Standard features across all desktop and laptop platforms include split tunneling, compression, activity-based imeouts, and automatic application launching.
For administrators, the FirePass device allows the restriction and protection of resources accessible through a connector by instituting rules that limit access to a specific network or port. It uses the standard HTTPS protocol with SSL as the transport, so it works through all HTTP proxies including public access points, private LANs, and over networks and ISPs that do not support traditional IPSec VPNs. And because it utilizes GZIP compression to compress traffic before it is encrypted, it reduces the amount of traffic that is sent across the Internet, improving performance.
To protect against backdoor attacks when accessing the network with split tunneling, the FirePass system provides a dynamic firewall that protects Win2k/XP users when using the full network access feature. This eliminates the ability for a hacker to route through the client to the corporate network or for the user to inadvertently send traffic to the public network.
FirePass also increases security by detecting the presence of required processes (e.g. virus scan, personal firewalls, OS patch levels, registry settings and McAfee anti-virus levels) and the absence of other processes (key logger for example) on the client PC before allowing full network access. Users who fail these primary policies can be connected to a quarantine network where they can update to current corporate security standards.
Enterprises increasingly deploy web-based applications, intranet and extranet portals, as well as web-based email to enable higher employee productivity and increased operational efficiency both internal to their organization as well as with their partners. To maximize the benefits of these applications, organizations should ensure these applications are accessible to employees and partners from any location while ensuring restricted, secure access only to authorized users.
The FirePass controller provides numerous features to ensure secure web-based access to enterprise intranet and extranet portals, web-based email,
and applications. The Portal Access capability works on any client OS with a [browser - Windows, Linux, Macintosh, Pocket PC's, PDAs and more.
Web Applications
The FirePass device provides access to internal Web servers, including Microsoft Outlook Web Access and Lotus iNotes , as easily as from inside the corporate LAN. It also delivers granular access control to intranet resources on a group basis. For example, employees can be provided access to all intranet sites; partners can be restricted to a specific web host.
While accessing resources, the FirePass controller dynamically maps internal URLs to external URLs so the internal network structure does not reveal them. User cookies are managed at the FirePass device to avoid exposing sensitive information. For applications that require access to cookies, the FirePass controller can pass cookies to the remote browser. User credentials can be passed to web hosts to support automatic login and other user specific access to applications. The FirePass controller also integrates with existing identity management servers (Netegrity for example) to enable single sign-on to applications.
File Server Access/Email Access
The FirePass controller allows users to browse, upload, download, copy, move or delete files on shared directories. It supports SMB Shares, Windows Workgroups; NT 4.0 and Win2000 domains; Novell 5.1/6.0 with Native File System pack, and NFS servers. For email, the FirePass device provides secure web-based access to POP/IMAP/SMTP email servers from standard and mobile device browsers. This allows users to send and receive messages, download attachments and attach network files to emails.
Mobile Device Support
The FirePass controller allows secure access from PDAs (like Palm OS), and cell phones (like WAP and iMode phones) to email and other applications. It dynamically formats email from POP/I MAP/SMTP email servers to fit the smaller screens of mobile phones and PDAs, and supports the sending of network files as email attachments and the viewing of text/Word documents.
Portal Access - Comprehensive Security
The FirePass controller delivers multiple layers of control for securing information access from public systems. For example, users of Windows 2000/XP can be automatically switched to a protected workspace for their remote access session. In a protected workspace mode, the user cannot write files to locations outside the protected workspace and the temporary folders and all of their contents are deleted at the end of the session. Since the user session is in a separate desktop, users are protected from trojan horses and key loggers.
The FirePass device also includes a cache cleanup control feature that removes cookies, browser history, auto-complete information, browser cache, temp files, and all ActiveX controls installed during the remote access session from the client PC. A secure "virtual keyboard" enables secure password entry from the mouse instead of the keyboard. When engaged, this feature enables users to securely enter a password on a system that has been compromised by a key logger.
For systems unable to install a "cleanup" control, the FirePass controller can be configured to block all file downloads to avoid the issue of inadvertently leaving behind temporary files - yet still allow access to applications. For users accessing web applications on the corporate network, the FirePass product enhances application security and prevents application-layer attacks (such as cross-site scripting, invalid characters, SQL injection, and buffer overflow) by scanning web application access for application-layer attacks - then blocking user access when an attack is detected. The FirePass device can also scan web and file uploads using either an integrated scanner or external scanner via ICAP API. Infected files are blocked at the gateway and not allowed onto email or file servers on the network, heightening protection.
Application Access - Secure Access to Specific Applications
FirePass allows administrators to grant certain users - for example, business partners using equipment not maintained by the company - access to specific extranet applications and sites. It protects network resources by only allowing access to applications that are specifically cleared by the system administrator. Supported applications include terminal servers, legacy hosts, Windows desktops, and X Windows systems. FirePass logs an audit trail of the specific applications accessed by each user to facilitate security audits.
Client/server Application Access
FirePass enables a native client side application to communicate back to a specific corporate application server via a secure connection between the browser and the FirePass Controller. It does not require the user to preinstall or configure any software. On the network side, FirePass requires no additional enabling software on the application servers being accessed. And because it uses the standard HTTPS protocol, with SSL as the transport, it works through all HTTP proxies including public access points, private LANs, and over networks and ISPs that do not support traditional IPSec VPNs. Supported applications include Outlook to Exchange Clusters; Passive FTP, Citrix Nfuse, and network drive mapping. Compression is also supported for better performance.
Terminal Server Access
FirePass provides secure Web-based access to Microsoft Terminal Servers, Citrix MetaFrame applications, Windows XP Remote Desktops, and VNC servers. It supports group access options, user authentication and automatic logon capabilities for authorized users, and supports automatic downloading and installation of the correct Terminal Services or Citrix remote-platform client component, if it is not currently installed on the remote device.
Desktop Access
FirePass allows secure remote control of Windows corporate desktops from Web browsers supporting Java or ActiveX downloads. It provides the ability to share the desktop with other users for Web-based collaboration or demonstrations and provides access to files, email and other applications.
Unix System Access and Host Access
FirePass supports secure access to Unix/Linux systems from Web browsers supporting Java or ActiveX downloads. It utilizes X Windows to natively communicate with Unix systems, without requiring modifications to the Unix system or application or requiring preinstalled X Windows client software. Host
Access features enable FirePass to secure web-based access to legacy VT100, VT320, Telnet, X-Term, and IBM 3270/5250 applications without requiring modifications to the applications or application servers.
Authentication and Authorization
The FirePass controller includes a dynamic policy engine that enables administrators to easily manage user authentication and authorization privileges. Dynamic policy based access gives administrators quick and granular control over their network resources. Through rules support, administrators can authorize access to applications based on the user and device being used. For example, administrators can configure a user's permission to allow email-only access from a public kiosk with active cache and temporary file cleanup, but provide them full network access from a corporate laptop with active firewall and virus detection software.
By default, users are authenticated against an internal FirePass database, using passwords. But the FirePass device can also be easily configured to work with RADIUS, Active Directory (Kerberos) and LDAP authentication methods, basic and form-based HTTP authentication, identity management servers (e.g. Netegrity),and Windows Domain Servers.
For authentication, many organizations require "two-factor" authentication, which uses something beyond knowledge of a user ID and password. FirePass fully supports RSA SecurlD token-based authentication. FirePass also offers a built-in implementation of VASCO Digipass .
In addition, the FirePass controller enables the administrator to restrict or permit access based on the device being used to access the FirePass device. The FirePass controller can also check for the presence of a client-side digital certificate during user login. This certificate will only be present on the laptop. Based on the presence of this digital certificate, the FirePass device can support access to a broader range of applications. The FirePass controller can also use the client-side certificate as a form of two-factor authentication and prohibit all network access for users without a valid client-side certificate. The FirePass device can act as a certificate authority and auto-generate and distribute client certificates. This drastically reduces the additional costs to purchase and manage certificates for each of the clients.
Access Privileges
Access privileges can be granted to individuals or to groups of users (for example: "Sales", "Partners", "IT"). This allows the FirePass device to restrict individuals and groups to particular resources.