Vous êtes sur la page 1sur 46



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 port and IP address 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 multibutton 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.



Ample options are there in now-a-days 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.


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


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.

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. 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. 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.

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 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 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. 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) Create a Socket Specify the address and service port of the server program Establish connection with the server Send and receive information Close the socket when finished, terminating the conversation

Reading from and Writing to a Socket ( for server) Create a Socket Listen for incoming connection from clients Accept the client connection Send and receive information 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 (rightmost) displayable pixel on the top line. The next 768 bytes are not displayable. Byte 2048 is the first (left-most) pixel on the second line from the top. The last













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 colors. 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 color palette which converts pixel values into RGB triplets.

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 colors can be represented, but the more memory is required to store or display the image. A color 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 colors - more than the human eye can distinguish. Microsoft Windows alls this true color. An image of 1024x768 with 24 bpp requires over 2 MB of memory. "High color" uses 16 bpp (or 15 bpp), 5 bits for blue, 5 bits for red and 6 bits for green. This reduced color precision gives a slight loss of image quality at a 1/3 saving on memory. Standard VGA uses a palette of 16 colors (4 bpp), each color in the palette is 24 bit. Standard SVGA uses a palette of 256 colors (8 bpp). Some graphics hardware and software support 32-bit color depths, including an 8-bit "alpha channel" for transparency effects.

3.1.13 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. 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. 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 state of these applications is preserved between accesses from different locations.

Protocol Version: Handshaking begins by the server sending the client a Protocol Version 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 Protocol Version message consists of 12 bytes interpreted as a string of ASCII characters in the format "RFB xxx.yyy\n" where xxx and yyy are the major and minor version numbers, padded with zeros.

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. 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 server's frame buffer, its pixel format and the name associated with the desktop: 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. 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.

3.2 WINDOWS REMOTE DESKTOP With the Remote Desktop feature in Windows, 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.1 Remote Control 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 the destination computer to make it look as if they were in front of it. With remote control software, it introduces several features, such as file transfer, video, mouse and keyboard emulation, security, and total control just to name a few. With the ability to manage


computers remotely, provides the chance of enhancing support, response times, and costs to any IT support groups and businesses. Some of the benefits of Remote control software are: 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





Processor RAM VDU Hard Disk : Intel Pentium compatible or above : 4MB free space : VGA/ S V G A : 50 MB free space


Operating System Programming language : MS DOS / Windows 95/Windows 7/ Linux : Java2 ( JDK 1.2)


The proposed system is going to be developed using Java 2.java is platform independent. Thus it will run under any operating system like Windows or Linux. The system explorer is mainly concentrated on the development of an application that is used to explore computers in a network. The main part of the application is a GUI that is used to browse other machines in the network. The GUI should be developed using Java Swing. The system should be modularized into a client part and a server part so that each part could be run separately. The server part should acts as the file server for the local client as well as the remote server. The client part should provide a GUI for easy user interaction. All request from the client are passed to the local server only. Requests to the remote server are forwarded by the local sever.

4.3.1 About Java

Java is an object-oriented programming language with a built-in application programming interface (API) that can handle graphics and user interfaces and that can be used to create


applications or applets. Because of its rich set of API's, similar to Macintosh and Windows, and its platform independence, Java can also be thought of as a platform in itself. Java also has standard libraries for doing mathematics. Much of the syntax of Java is the same as C and C++. One major difference is that Java does not have pointers. However, the biggest difference is that you must write object oriented code in Java. Procedural pieces of code can only be embedded in objects. In the following we assume that the reader has some familiarity with a programming language. In particular, some familiarity with the syntax of C/C++ is useful. In Java we distinguish between applications, which are programs that perform the same functions as those written in other programming languages, and applets, which are programs that can be embedded in a Web page and accessed over the Internet. Our initial focus will be on writing applications. When a program is compiled, a byte code is produced that can be read and executed by any platform that can run Java. Java is a high-level, third generation programming language, like C, Fortran, Smalltalk, Perl, and many others. You can use Java to write computer applications that crunch numbers, process words, play games, store data or do any of the thousands of other things computer software can do. Compared to other programming languages, Java is most similar to C. However although Java shares much of C's syntax, it is not C. Knowing how to program in C or, better yet, C++, will certainly help you to learn Java more quickly, but you don't need to know C to learn Java. Unlike C++ Java is not a superset of C. A Java compiler won't compile C code, and most large C programs need to be changed substantially before they can become Java programs. What's most special about Java in relation to other programming languages is that it lets you write special programs called applets that can be downloaded from the Internet and played safely within a web browser. Traditional computer programs have far too much access to your system to be downloaded and executed willy-nilly. Although you generally trust the maintainers of various ftp archives and bulletin boards to do basic virus checking


and not to post destructive software, a lot still slips through the cracks. Even more dangerous software would be promulgated if any web page you visited could run programs on your system. You have no way of checking these programs for bugs or for out-and-out malicious behavior before downloading and running them. Java solves this problem by severely restricting what an applet can do. A Java applet cannot write to your hard disk without your permission. It cannot write to arbitrary addresses in memory and thereby introduce a virus into your computer. It should not crash your system. Java is a platform for application development. A platform is a loosely defined computer industry buzzword that typically means some combination of hardware and system software that will mostly run all the same software. For instance PowerMacs running Mac OS 9.2 would be one platform. DEC Alphas running Windows NT would be another. There's another problem with distributing executable programs from web pages. Computer programs are very closely tied to the specific hardware and operating system they run. A Windows program will not run on a computer that only runs DOS. A Mac application can't run on a Unix workstation. VMS code can't be executed on an IBM mainframe, and so on. Therefore major commercial applications like Microsoft Word or Netscape have to be written almost independently for all the different platforms they run on. Netscape is one of the most cross-platform of major applications, and it still only runs on a minority of platforms. Java solves the problem of platform-independence by using byte code. The Java compiler does not produce native executable code for a particular machine like a C compiler would. Instead it produces a special format called byte code. Java byte code written in hexadecimal, byte by byte, looks like this: This looks a lot like machine language, but unlike machine language Java byte code is exactly the same on every platform. This byte code fragment means the same thing on a Solaris workstation as it does on a Macintosh PowerBook. Java programs that have been compiled into byte code still need an interpreter to execute them on any given platform.


The interpreter reads the byte code and translates it into the native language of the host machine on the fly. The most common such interpreter is Sun's program java (with a little j). Since the byte code is completely platform independent, only the interpreter and a few native libraries need to be ported to get Java to run on a new computer or operating system. The rest of the runtime environment including the compiler and most of the class libraries are written in Java. All these pieces, the javac compiler, the java interpreter, the Java programming language, and more are collectively referred to as Java. Java was designed to make it much easier to write bug free code. According to Sun's Bill Joy, shipping C code has, on average, one bug per 55 lines of code. The most important part of helping programmers write bug-free code is keeping the language simple. Java has the bare bones functionality needed to implement its rich feature set. It does not add lots of syntactic sugar or unnecessary features. Despite its simplicity Java has considerably more functionality than C, primarily because of the large class library. Because Java is simple, it is easy to read and write. Obfuscated Java isn't nearly as common as obfuscated C. There aren't a lot of special cases or tricks that will confuse beginners. About half of the bugs in C and C++ programs are related to memory allocation and deallocation. Therefore the second important addition Java makes to providing bug-free code is automatic memory allocation and deallocation. The C library memory allocation functions malloc() and free() are gone as are C++'s destructors. Java is an excellent teaching language, and an excellent choice with which to learn programming. The language is small so it's easy to become fluent. The language is interpreted so the compile-run-link cycle is much shorter. The runtime environment provides automatic memory allocation and garbage collection so there's less for the programmer to think about. Java is object-oriented unlike Basic so the beginning programmer doesn't have to unlearn bad programming habits when moving into real


world projects. Finally, it's very difficult (if not quite impossible) to write a Java program that will crash your system, something that you can't say about any other language. Object oriented programming is the catch phrase of computer programming in the 1990's. Although object oriented programming has been around in one form or another since the Simula language was invented in the 1960's, it's really begun to take hold in modern GUI environments like Windows, Motif and the Mac. In object-oriented programs data is represented by objects. Objects have two sections, fields (instance variables) and methods. Fields tell you what an object is. Methods tell you what an object does. These fields and methods are closely tied to the object's real world characteristics and behavior. When a program is run messages are passed back and forth between objects. When an object receives a message it responds accordingly as defined by its methods. Object oriented programming is alleged to have a number of advantages including:

Simpler, easier to read programs More efficient reuse of code Faster time to market More robust, error-free code

In practice object-oriented programs have been just as slow, expensive and buggy as traditional non-object-oriented programs. In large part this is because the most popular object-oriented language is C++. C++ is a complex, difficult language that shares all the obfuscation of C while sharing none of C's efficiencies. It is possible in practice to write clean, easy-to-read Java code. In C++ this is almost unheard of outside of programming textbooks. Java was designed to not only be cross-platform in source form like C, but also in compiled binary form. Since this is frankly impossible across processor architectures Java is compiled to an intermediate form called byte-code. A Java program never really executes natively on the host machine. Rather a special native program called the Java interpreter reads the byte code and executes the corresponding native machine instructions. Thus to port Java programs to a new platform all that is needed is to port the


interpreter and some of the library routines. Even the compiler is written in Java. The byte codes are precisely defined, and remain the same on all platforms. Java is inherently multi-threaded. A single Java program can have many different threads executing independently and continuously. Three Java applets on the same page can run together with each getting equal time from the CPU with very little extra effort on the part of the programmer. This makes Java very responsive to user input. It also helps to contribute to Java's robustness and provides a mechanism whereby the Java environment can ensure that a malicious applet doesn't steal all of the host's CPU cycles. The compiler searches the current directory and directories specified in the CLASSPATH environment variable to find other classes explicitly referenced by name in each source code file. If the file you're compiling depends on other, non-compiled files the compiler will try to find them and compile them as well. The compiler is quite smart, and can handle circular dependencies as well as methods that are used before they're declared. It also can determine whether a source code file has changed since the last time it was compiled. More importantly, classes that were unknown to a program when it was compiled can still be loaded into it at runtime. For example, a web browser can load applets of differing classes that it's never seen before without recompilation. Furthermore, Java .class files tend to be quite small, a few kilobytes at most. It is not necessary to link in large runtime libraries to produce a (non-native) executable. Instead the necessary classes are loaded from the user's CLASSPATH. We do not need to explicitly allocate or deallocate memory in Java. Memory is allocated as needed, both on the stack and the heap, and reclaimed by the garbage collector when it is no longer needed. There's no malloc(), free(), or destructor methods. There are constructors and these do allocate memory on the heap, but this is transparent to the programmer.


The exact algorithm used for garbage collection varies from one virtual machine to the next. The most common approach in modern VMs is generational garbage collection for short-lived objects, followed by mark and sweep for longer lived objects. I have never encountered a Java VM that used reference counting.





Fig. 5.1 E-R diagram



Fig 5.2:Client-Server Connection

Fig 5.3: Sequence Diagram





Client CommandSender
package RemoteServer; Import java.awt.Rectangle; import java.awt.event.KeyEvent; import java.awt.event.KeyListener; import java.awt.event.MouseEvent; import java.awt.event.MouseListener; import java.awt.event.MouseMotionListener; import java.io.IOException; import java.io.PrintWriter; import java.net.Socket; import javax.swing.JPanel;

class ClientCommandsSender implements KeyListener, MouseMotionListener,MouseListener {

private Socket cSocket = null; private JPanel cPanel = null; private PrintWriter writer = null; private Rectangle clientScreenDim = null;


Client Handler
/*The server that the clients connect to and a gui for the clients. When the server picks up a new connection from a client it starts a new thread running that handles all the different operations. The p server accepts the new client and start a new client handler thread running */

package RemoteServer; import java.awt.BorderLayout; import java.awt.Rectangle; import java.beans.PropertyVetoException; import java.io.IOException; import java.io.ObjectInputStream; import java.net.Socket; import javax.swing.JDesktopPane; import javax.swing.JInternalFrame; import javax.swing.JPanel;

class ClientHandler extends Thread {

private JDesktopPane desktop = null; private Socket cSocket = null; private JInternalFrame interFrame = new JInternalFrame("Client Screen", true, true, true); private JPanel cPanel = new JPanel();

Client ScreenReciever


package RemoteServer;

import java.awt.Graphics; import java.awt.Image; import java.io.IOException; import java.io.ObjectInputStream; import javax.swing.ImageIcon; import javax.swing.JPanel;

/** * ClientScreenReciever is responsible for recieving client screenshot and displaying * it in the server. Each connected client has a separate object of this class */ class ClientScreenReciever extends Thread {

private ObjectInputStream cObjectInputStream = null; private JPanel cPanel = null; private boolean continueLoop = true;

public ClientScreenReciever(ObjectInputStream ois, JPanel p) { cObjectInputStream = ois; cPanel = p; //start the thread and thus call the run method start();

Ennum Command


package RemoteServer; /** * Used to represent commands which can be sent by the server */ public enum EnumCommands { PRESS_MOUSE(-1), RELEASE_MOUSE(-2), PRESS_KEY(-3), RELEASE_KEY(-4), MOVE_MOUSE(-5);

private int abbrev;

EnumCommands(int abbrev){ this.abbrev = abbrev; }

public int getAbbrev(){ return abbrev; } }

Client Side Implementation

package RemoteClient;


import java.awt.AWTException; import java.awt.Dimension; import java.awt.GraphicsDevice;

/** * * This class is responsible for connecting to the server * and starting ScreenSpyer and ServerDelegate classes */ public class ClientInitiator {

Socket socket = null;

public static void main(String[] args){ String ip = JOptionPane.showInputDialog("Please enter server IP"); String port = JOptionPane.showInputDialog("Please enter server port"); new ClientInitiator().initialize(ip, Integer.parseInt(port)); }

public void initialize(String ip, int port ){

Robot robot = null; //Used to capture the screen

package RemoteClient;


/** * Used to represent commands which can be sent by the server */ public enum EnumCommands { PRESS_MOUSE(-1), RELEASE_MOUSE(-2), PRESS_KEY(-3), RELEASE_KEY(-4), MOVE_MOUSE(-5);

private int abbrev;

EnumCommands(int abbrev){ this.abbrev = abbrev; }

public int getAbbrev(){ return abbrev; } }

package RemoteClient;

/** * This class is responisble for sending screenshot every predefined duration */


class ScreenSpyer extends Thread {

Socket socket = null; Robot robot = null; // Used to capture screen Rectangle rectangle = null; //Used to represent screen dimensions boolean continueLoop = true; //Used to exit the program

public ScreenSpyer(Socket socket, Robot robot,Rectangle rect) { this.socket = socket; this.robot = robot; rectangle = rect; start(); }

public void run(){ ObjectOutputStream oos = null; //Used to write an object to the streem

try{ //Prepare ObjectOutputStream oos = new ObjectOutputStream(socket.getOutputStream()); /* * Send screen size to the server in order to calculate correct mouse

package RemoteClient;


import java.awt.Rectangle; import java.awt.Robot; import java.awt.image.BufferedImage; import java.io.IOException; import java.io.ObjectOutputStream; import java.net.Socket; import javax.swing.ImageIcon;

/** * This class is responisble for sending screenshot every predefined duration */ class ScreenSpyer extends Thread {

Socket socket = null; Robot robot = null; // Used to capture screen Rectangle rectangle = null; //Used to represent screen dimensions boolean continueLoop = true; //Used to exit the program

public ScreenSpyer(Socket socket, Robot robot,Rectangle rect) { this.socket = socket; this.robot = robot; rectangle = rect; start(); }

public void run(){


ObjectOutputStream oos = null; //Used to write an object to the streem

try{ //Prepare ObjectOutputStream oos = new ObjectOutputStream(socket.getOutputStream()); /* * Send screen size to the server in order to calculate correct mouse * location on the server's panel */ oos.writeObject(rectangle); }catch(IOException ex){ ex.printStackTrace(); }

while(continueLoop){ //Capture screen BufferedImage image = robot.createScreenCapture(rectangle); /* I have to wrap BufferedImage with ImageIcon because BufferedImage class * does not implement Serializable interface */ ImageIcon imageIcon = new ImageIcon(image);

//Send captured screen to the server try { System.out.println("before sending image");


oos.writeObject(imageIcon); oos.reset(); //Clear ObjectOutputStream cache System.out.println("New screenshot sent"); } catch (IOException ex) { ex.printStackTrace(); }

//wait for 100ms to reduce network traffic try{ Thread.sleep(100); }catch(InterruptedException e){ e.printStackTrace(); } } } }




Remote Desktop Controller is a client -server software used for remote desktop access and controlling purposes. This software mainly runs as two parts, the one at the client side using which the user views the desktop of the system at the remote side acting as the server and controls it and the server side which allows it to be accessed and controlled by the client user. This software is basically divided into two module based on this purpose. 1. The Server module - running on the remote system acting as the server system which allows itself to be accessed by the client user. 2. The Client module - running on the client system through which the user accesses and controls the remote server system.



The server system is the system being controlled by the remote user at the client side. It shares its desktop with the client user and allows it to be controlled by the client user with the required priority. The server module mainly consists of: 1.1 The Startup and Broadcasting module - this module starts running whenever a user starts the server programming running. This major purpose of this module is to help the client systems find out which all server systems are running and their status. 1.2 The Desktop Controlling module - this module in the server system starts executing when a client system selects that server and try to access.



When a server starts running the broadcasting module starts running and will be continue executing till the server program is stopped. This module doesn't deal with the actual desktop controlling purpose of the software. It helps the client systems find out which all server systems are running at present and their availability status, i.e. whether that server is already controlled by any other system (OCCUPIED) or whether it's free to be accessed (AVAILABLE).

The major modules coming under the broadcasting module are:

7.2.1 The Startup and password setting module : The server allows different types of access privileges to the connecting remote user.

View Only Access - in this type of access the user at the remote end is allowed to

only view the server systems desktop. No control is allowed.

Full Control Access - in this type of access the user working at the client side is

allowed full control over the server. I.e. the user at the client is allowed to view the server systems desktop and the mouse and keyboard control is also allowed. Whenever a server is started it asks the user to set passwords to control the access. Passwords for View Only access and Full Control Access are to be entered. When a client user tries to connect to the server, he is asked for the password. Depending on the password he enters corresponding access privilege is allowed. The password entered is valid for one session. The next time the server starts up the user is again asked to setup the access control passwords. 7.2.2 The Message Broadcasting module: This module generates message packets consisting of details like IP address or hostname of the server, availability status and the time. These message packets


generated are transmitted through the network every two seconds by this module. Format of the message string: IP address | availability | time.


The actual desktop sharing starts in the Desktop controlling module. This module allows the server system to capture desktop images and send it to the remote client. The simulation of remote of mouse and keyboard events occurring at the client is also done in this module.

This module mainly consists of:

7.3.1. The Desktop Capturing and Sending module: In this module the snap shots of the servers' desktop are taken in regular intervals and send to the client system. When a server is connected to the client system, this module starts running and for the first time the entire image of the desktop is send to the client for viewing, from the second time onwards the entire image of the desktop is subdivided into blocks of 8*8 i.e. 64 blocks and each block is compared with the previous block send at the corresponding position. The blocks in which there is a considerable change are send to the client. This method is implemented to speed up the desktop transferring process and reduce network traffic by considerably reducing the packet size. 7.3.2.Simulating Mouse Events module: The simulation of mouse events corresponding to the events occurring at the client side is another major function of the desktop controlling module. The client sends messages to the server for each mouse events occurring there and the corresponding events are simulated at the server system.


7.3.3 Simulating Keyboard Events module: Messages corresponding to each keyboard events occurring at the client side are send to the server system. This module is used to process those messages and simulate respective events at the server system.


The client system is the system through which the user accesses and controls the remote system acting as the server. The client module mainly consists of:

The Server Listing and Connection Establishment module:

This module starts running when a client program is run on a system. The major purpose of this module is to list all the servers running and establishing connection to the required server.

The Desktop Controlling module: This module in the client system starts executing when a client user selects a remote server system and try to access it.


In the client side of the software there is a Graphical User Interface to list all the available servers running and their status i.e. whether they are available or already occupied or accessed by any other client system. The user will be shown in a table the running servers' ip address or host name and the respective availability status. The user can then click and select the respective system required and request for connection to it. If the server is a free one i.e. it is not already in use by any other client, then the user is asked to enter the access control password and depending on the password entered, the connection will be allowed and the required ports data


transmission are allocated. If the user tries to access an already occupied server the connection will not be allowed.

The modules coming under this are:

7.5.1 The Server Listing Module: In this module a port is allocated to read in broadcast messages send by the server systems. These messages are read in by this module and processed. According to these incoming messages the running servers and their availability are listed. The time is taken to check with the previous list whether a server has stopped running or the availability has changed. If the message from a particular server hasn't been received within a time period of three seconds, then that server is removed from the list. 7.5.2 The Connection Establishment module: From the list of available servers the client user can select the system he wants to connect and control. The user can click and select the system required and connect to it by clicking the connect button. Then the user is requested to enter the password for authenticating access with the required priority to the server system.

If the password entered is corresponding to that of view only access, only the

ports required for respective data transfer are allocated and data transfer is started. If the password entered is corresponding to that of full access priority then all

the ports required are allocated and data transfer is started. If the password entered is a wrong one an error message saying that the entered

password is wrong is shown and the connection will not be allowed.


7.6 The Desktop Controlling module

The desktop of the remote server system is controlled by the client user by using this module. The major sub modules coming under this are:

7.6.1 The Desktop Receiving and Displaying module In this module, the snap shots of the servers" desktop send by the server module are received in regular intervals. When the client gets connected to remote server system, this module starts running and for the first time the entire image of the server desktop is loaded at the client sides viewing interface. From the second time onwards the server system will only send the blocks in which there is a difference with the previous image sent. The blocks are read in and are painted to the corresponding positions in the viewing interface at the client side. This method is implemented to speed up the desktop transferring and loading process and reduce network traffic by considerably reducing the packet size. 7.6.2 Tracking and Sending Mouse Events module: Mouse events occurring at the client side are tracked and the corresponding control messages required to control the remote server are generated. These messages generated are sent to the server for simulation 7.6.3 Tracking and Sending Keyboard Events module : Messages corresponding to each keyboard events occurring at the client side are generated and sent to the remote server system under control for simulation.

7.7 Rationale behind coding

The entire code of the program has been modularized to increase the readability workability, and understandability of the code. The two main modules, server and client are so coded that they can work independently. Modularization has enhanced the threaded working pattern of the program.





Figure 7.1: Client Initialization by providing server IP


Figure 7.2: Client Initialization by providing Server port



Figure 7.3: Server:After entering the listening port : 3000


Figure 7.4: When the Connection is established successfully


Figure 7.5: Client Screen on Server PC




In the networking environment the Administrator have to control the whole thing. So efficient computing capabilities are therefore made. The project "REMOTE DESKTOP CONTROLLER" after being tested and was found to be achieving what is meant for. Security is the main consideration in this project. The system is protected from any unauthorized access by giving user name and password during log in process the system is made in such a way that it can be modified with very less time. This is also very user-friendly. The software which I developed was implemented and tested with real data and were found to be error free. Also, it is found that the system will work successfully. All the necessary validations are carried out in this project, so that any kind of users can make use of this software and necessary messages makes them conscious of the error they have made It does not provide a complete solution for the entire problem in the user point of view. The system is found 100% error free and is ready for implementation.


The Technology is growing very fast and in the Networking environment the administrator had to control the whole thing. Remote system controlling has huge potential in the Internet-based and service-oriented architectures .To survive from the competition each system has to produce some modifications to it in the future. New features will provide the system a new fresh look, by which it can attract a lot of Administrators. Due to this reason it's necessary that the system need to be modified according to the users requirements. Some of the future enrichments are as follows: The utility at present meant for intranet environments and has a wide range of application areas like virtual classrooms


Next generation of this utility package is supposed on internet based applications Further variations aim to include added capabilities such as controls and more user controls on Remote Machines A request queue for the server to handle multiple simultaneous requests for the same file Compressing the file before sending them to a requested system and decompressing on reception.




http:/www.sun.com.java Open Group, X11R6.3 (Broadway) Overview, http://www.opengroup.org James Keogh, Complete Reference J2ME, TataMcGraw-Hill,2004, New Delhi. www.iplab.cs.tukuba.ac.jp/~shizuki/r/papers/svnc-csn2002.pdf. T. Richardson et al., Teleporting in an X Window System Environment, T. Richardson, TeleportingMobile X Sessions, K.R Wood et al., Global Teleporting with Java: Toward Ubiquitous Personalized Computing,