Vous êtes sur la page 1sur 61



Cellular phones have shown a dramatic improvement in their functionality to a point where it is now possible to have cellular phones execute Java programs. As a result, cellular users throughout Japan are now able to read and write e-mail, browse Web pages, and play Java games using their cellular phones. This trend has prompted us to propose the use of a cellular phone as a device for remotely controlling computers. For example, if a cellular user is able to remotely access computers (such as workstations in offices and personal computers (PCs) in homes) or other networked digital appliances, it would provide the user with the following capabilities: to see the contents of a file placed on the desktop of a remote computer. to reboot a remote server as an administrator. While it is not very difficult to develop a specific system to satisfy each of the above operations separately, it lacks the generality needed for performing several such functions with one device. This paper presents a virtual network computing(VNC) based architecture for accessing the desktop of various remote systems (such as MS Windows, Macintosh, and UNIX systems) from a cellular phone. It is assumed that the remote computer system is running a VNC server and that it is attached to a network. The cellular user can see and manipulate the desktop on the cellular phone..


In the existing system they used two PCs. Where one of the pc acted as the VNC viewer and other used VNC server In the existing system the user can be access that the Remote computer from one to another PC.

This kind of environment can be used in the software industry to communicate between system connected within the LAN.

There is no portability in the existing system. No security. This kind of environment does not enhance portability. Such kind of concept does not ensure security too.

In our proposed system we can access that the remote computer using that the Java enabled Mobile phones. In this system we use a cellular phones with internet connectivity and a personal computed. The desktop of the PC can be viewed on the mobile phone depending on the resolution of the mobile PC on the mobile. We can perform many operations such as viewing that Desktop of the PC, Accessing Applications in the PC, etc.

The mobile is easily portable thereby portability exists also one can set security authentication. There by security is highly enhanced. In order to increase the speed of the pointed the speed can be enhanced, which exists. Also one can view the desktop either in normal and full mode. Navigation of screen is also possible.

1.4 VNC
VNC stands for Virtual Network Computing. It is, in essence, a remote display system which allows you to view a computing 'desktop' environment not only on the

machine where it is running, but from anywhere on the Internet and from a wide variety of machine architectures. No state is stored at the viewer. This means you can leave your desk, go to another machine, whether next door or several hundred miles away, reconnect to your desktop from there and finish the sentence you were typing. Even the cursor will be in the same place. With a PC X server, if your PC crashes or is restarted, all the remote applications will die. With VNC they go on running. It is small and simple. The Win32 viewer, for example, is about 150K in size and can be run directly from a floppy. There is no installation needed. 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. We have a Java viewer, which will run in any Java-capable browser. We have a Windows NT server, allowing you to view the desktop of a remote NT machine on any of these platforms using exactly the same viewer

The VNC-based architecture

To achieve the above-mentioned goals while at the same

Fig 1

time considering portability and generality, we propose a VNC based architecture. VNC is an implementation of a remote display system based on a Remote Frame Buffer (RFB) protocol.

It consists of VNC servers running on one or more remote computers, a Smart VNC (SVNC) proxy, and a SVNC viewer on a cellular phone. A VNC server sends a remote desktop display as bitmap images in RFB protocol. A SVNC proxy converts (crops, shrinks and resamples) the display image and then transfers the converted image to a SVNC viewer in response to a user request that was received from that SVNC viewer. The transfer is performed in our own Compact RFB (CRFB), our simplified RFB protocol. Then, the SVNC viewer displays the transferred images. Key events received by the SVNC viewer are transmitted to a SVNC proxy that coverts them and sends them to the server. When the user first tries to connect to a remote computer, he must specify his user name and password for authentication as well as the host name of the computer that is running a VNC server. If authentication succeeds, the SVNC proxy establishes a session with the VNC server and the SVNC viewer starts user services. To suppress network traffic, encoding is changed depending on contexts. Usually, colored display images are transferred from the SVNC proxy to the SVNC viewer. However, while the user is manipulating the remote desktop, such as scrolling and moving the pointing device, the display images are gray-scaled to reduce the number of bytes required to encode the image.

An Architecture for Cellular Phones

The use of existing remote display protocols such as the X Window System Protocol and the Remote Desktop Protocol of Microsofts Windows 2000 Terminal Services does not provide the required capability to realize the following goals:

Convert different devices: A cellular phone is physically limited. The typical size of
the screen is 2.2 inches with 120x130 pixels. SVNC viewer on a emulator accessing the desktop of a remote Linux about sixteen keys. In contrast, current desktops are manipulated with keyboards that have over 100 keys and pointing devices such as a mouse. 4

Suppress network traffic: The wireless transmission bandwidth available for a

cellular phone is limited. Currently, it is 384k bps, even on IMT-2000 based services (only downstream at this transmission rate).

Recover from an unscheduled disconnection: Because of its wireless nature,

stable network connectivity cannot be expected. For example, when the user goes into a tunnel or a building, established connections can be lost. In addition, in order to use the same cellular phone to talk to someone, the user must terminate the network connection.

Suppress computational resource use: CPU performance and memory size are
limited on a cellular phone to achieve portability and to lower power consumption.

Applications of VNC
VNC has a wide range of applications including system administration, IT support and helpdesks. It can also be used to support the mobile user, both for hot desking within the enterprise and also to provide remote access at home, or on the road. The system allows several connections to the same desktop, providing an invaluable tool for collaborative or shared working in the workplace or classroom. Computer support within the geographically spread family is an ever popular useVNC Enterprise Edition is an enhanced version of the industry-standard VNC, developed for use in corporate environments and across the Internet. Designed and built from the ground up by the original inventors of VNC, Enterprise Edition provides robust and easily-administered security with a minimum of fuss. The core Enterprise Edition features, common across all supported platforms, are as follows.

Platform-Native Authentication removes the need for separate VNC and system passwords. Users can access their desktops using the same credentials with which they log on to the system.

One-Port HTTP & VNC allows VNC Server to serve VNC Viewer for Java and VNC sessions through a single TCP port, simplifying NAT and firewall configuration.

Desktop Scaling to a particular size, by a particular ratio, or dynamically to whatever size you choose.

Windows Firewall Integration, making VNC Server more straightforward to deploy. Cross-Platform Interoperability with the other members of the VNC Enterprise family. File Transfer allows you to copy files between your server and viewer computers over the VNC connection.

Common Uses For VNC

Workstation toWorkstation (Windows) - In a PCsupport environment this would arguably be the most useful. With the server software loaded onto each machine on the network, and the viewer on restricted machines (or carried around on a floppy disk by support personnel) it would be easy for remote diagnostics to be carried out on PCs that were located remotely (perhaps many miles away), either via the company WAN or a dial-up connection to the remote PC. The issue of monitoring/spying also crops up here - if it is suspected that a member of staff is not utilising his/her time correctly, then the viewer, if connected in View Only mode, can easily snoop on the user. This could be done by a technician, or even someone senior who might not have the relevant technical skills; in View Only mode no real technical skills are required to start up, view, and subsequently shut down the software. Workstation to Server This would enable a viewer on any type of workstation (or WindowsCE machine) to connect to a server running one of the supported operating systems, so allowing remote control (or monitoring) of that server. The most common uses here would be for server control/monitoring from the support persons desk while at work, or when dialling into the server from home (the viewer software being run on a laptop, desktop or WindowsCE machine). Workstation to Workstation (cross-platform) - Because server and viewer software is also available for the Macintosh machines it is now possible to remotely run, for example, a non-Windows-compliant application on aWindows machine, so enabling a vast array of Macintosh software to effectively be run onWindows PCs (albeit a little slowly and with some obvious restrictions on functionality).

Thin Client - As VNC is Thin Client software it is possible for an older, poorly-specified PC to connect to a better-specified serverPCandremotely run software that would not have been possible on the lesser PC, either due to memory, harddrive or power restrictions. However, although it is possible to connect from multiple machines, all these machines will only be able to monitor/control the one Windows desktop - ie, VNC does not turn a server into a true multi-user server in the way that the Citrix products can. The X-based VNC server is more flexible in this respect. shared leaves open any existing server connections so the desktop can be shared with other users. For security reasons this is usually not possible, but this command overrides the default setting. 8bit any colour depths are usually allowed, with translation to lower bits automatically carried out as required. This overrides the default, so making it useful for lower-speed lines (such as modem dial-ups). emulate3 emulates three buttons on a two-button mouse (simultaneously clicking both buttons emulates the third). fullscreen causes the viewer to start in full-screen mode instead of windowed. listen with this set, the server can initiate connections to the viewer.





General Packet Radio Services (GPRS) is a packet-based wireless communication service that promises data rates from 56 up to 114 Kbps and continuous connection to the Internet for mobile phone and computer users. The higher data rates allow users to take part 7

in video conferences and interact with multimedia Web sites and similar applications using mobile handheld devices as well as notebook computers. GPRS is based on Global System for Mobile (GSM) communication and complements existing services such circuitswitched cellular phone connections and the Short Message Service (SMS). In theory, GPRS packet-based services cost users less than circuit-switched services since communication channels are being used on a shared-use, as-packets-are-needed basis rather than dedicated to only one user at a time. It is also easier to make applications available to mobile users because the faster data rate means that middleware currently needed to adapt applications to the slower speed of wireless systems are no longer be needed. As GPRS has become more widely available, along with other 2.5G and 3G services, mobile users of virtual private networks (VPNs) have been able to access the private network continuously over wireless rather than through a rooted dial-up connection. GPRS also complements Bluetooth, a standard for replacing wired connections between devices with wireless radio connections. In addition to the Internet Protocol (IP), GPRS supports X.25, a packet-based protocol that is used mainly in Europe. GPRS is an evolutionary step toward Enhanced Data GSM Environment (EDGE) and Universal Mobile Telephone Service (UMTS). GPRS uses a packet-mode technique to transfer high-speed and low-speed data and signalling in an efficient manner over GSM radio networks. GPRS data speeds are expected to reach theoretical data speeds of up to 171.2 Kbps. By implementing GPRS, the following objectives can be met: give support for bursty traffic use efficiently network and radio resources provide flexible services at relatively low costs possibility for connectivity to the Internet provide fast access time to have and support flexible co-existence with GSM voice




: JAVA(Gel editor)

J2ME Wireless Toolkit


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: CA FE BA BE 00 03 00 2D 00 3E 08 00 3B 08 00 01 08 00 20 08 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. The second important part of making Java cross-platform is the elimination of undefined or architecture dependent constructs. Integers are always four bytes long, and floating point variables follow the IEEE 754 standard for computer arithmetic exactly. You don't have to worry that the meaning of an integer is going to change if you move from a Pentium to a PowerPC. In Java everything is guaranteed. However the virtual machine itself and some parts of the class library must be written in native code. These are not always as easy or as quick to port as pure Java programs. This is why for example, there's not yet a version of Java 1.2 for the Mac. Java was designed from the ground up to allow for secure execution of code across a network, even when the source of that code was untrusted and possibly malicious. This required the elimination of many features of C and C++. Most notably there are no pointers in Java. Java programs cannot access arbitrary addresses in memory. All memory access is handled behind the scenes by the (presumably) trusted runtime environment. Furthermore Java has strong typing. Variables must be declared, and 13

variables do not change types when you aren't looking. Casts are strictly limited to casts between types that make sense. Thus you can cast an int to a long or a byte to a short but not a long to a boolean or an int to a String. Java implements a robust exception handling mechanism to deal with both expected and unexpected errors. The worst that an applet can do to a host system is bring down the runtime environment. It cannot bring down the entire system. Most importantly Java applets can be executed in an environment that prohibits them from introducing viruses, deleting or modifying files, or otherwise destroying data and crashing the host computer. A Java enabled web browser checks the byte codes of an applet to verify that it doesn't do anything nasty before it will run the applet. However the biggest security problem is not hackers. It's not viruses. It's not even insiders erasing their hard drives and quitting your company to go to work for your competitors. No, the biggest security issue in computing today is bugs. Regular, ordinary, non-malicious unintended bugs are responsible for more data loss and lost productivity than all other factors combined. Java, by making it easier to write bug-free code, substantially improves the security of all kinds of programs. Java byte codes can be compiled on the fly to code that rivals C++ in speed using a "just-in-time compiler." Several companies are also working on native-machine-architecture compilers for Java. These will produce executable code that does not require a separate interpreter, and that is indistinguishable in speed from C++. While you'll never get that last ounce of speed out of a Java program that you might be able to wring from C or Fortran, the results will be suitable for all but the most demanding applications. It is certainly possible to write large programs in Java. The HotJava browser, the Eclipse integrated development environment, the LimeWire file sharing application, the jEdit text editor, the JBoss application server, the Tomcat servlet container, the Xerces XML parser, the Xalan XSLT processor, and the javac compiler are large programs that are written entirely in Java. 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. Unfortunately multithreading is so tightly integrated with Java, that it makes Java rather difficult to port to architectures like Windows 3.1 or the PowerMac that don't natively support preemptive multi-threading. There is a cost associated with multi-threading. Multi-threading is to Java what pointer arithmetic is to C, that is, a source of devilishly hard to find bugs. Nonetheless, in simple programs it's possible to leave multi-threading alone and normally be OK. Java does not have an explicit link phase. Java source code is divided into .java files, roughly one per each class in your program. The compiler compiles these into .class files containing byte code. Each .java file generally produces exactly one .class file. (There are a few exceptions we'll discuss later in the semester, non-public classes and inner classes). 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. You 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. 2.2.2 ABOUT VNC SERVER The main server program needs to be run on the host machine so viewers have something to connect to. The server is currently available for X (Unix), Windows and PPC Macintosh. There is also a version called RFB counter, which is a simple server produced with the aim of demonstrating that things other than desktops can be displayed. Under Windows, the server can be run as an application or service, but for various reasons it is recommended to run it as a service (for example, a user doesnt then need to be logged into the server machine before a viewer can access it). Once installed, the server can be set up to allow viewers to access it. I will use the Windows version as an example. In this case, all the default settings can be used for an easy test startup, and the only thing that you will need to do is enter a password for viewer access. Failure to do so will result in a dialog box with a security warning message which then takes you back to the Properties page, so forcing a password to be entered. Besides the options available via the Properties page, various command-line options are also available. It is prohibitive to list them all here, so instead I have listed a few examples:


Install- installs the WinVNC Service Kill - kills a running copy of WinVNC about shows the About box It is also possible to run WinVNC from the command line with multiple options, so

combining commands on one line. Quite a number of advanced settings are also available under WinVNC, but these are somewhat more fiddly to configure because the registry needs to be edited. Ways of simplifying this process are currently being looked into for implementation into future revisions. 2.2.3 ABOUT VNC VIEWER The viewer is run on the remote machine that will be connecting to the server. The viewer is currently available for X (Unix), Windows, Java, Macintosh (requires MacOS 7.1 or greater plus Open Transport 1.1.1 or greater) and WindowsCE (requiresWindows CE 2.0 or later). The following information covers the use of the Windows VNC viewer. No installation or configuration is necessary - the executable is simply run from hard drive or floppy disk, either by double-clicking the icon or typing in the name of the VNC executable via the command line. Once started, a dialog box is displayed prompting for the name or IP address of the server . After that, the user is prompted for the session password (as previously configured via the server software). Successful authentication brings up a virtual display of the servers desktop. An Options button is available - clicking on this displays the options. Out of all the available options, View Only is the one that is the most interesting, since it allows the viewer to view activity on the server without the server being controlled in any way by the viewer. This is especially useful for monitoring purposes (monitoring a backup program running on a server, for example) or for spying purposes ie, keeping tabs on how users are utilising their machines. This latter use would no doubt create some controversy in some circles - after all, no-one likes to be spied on - but it does have a valid use in certain circumstances. Once connected to the server, the viewer can control it as if the user was sitting at the remote machine. I found the speed to be good on a 10Mbits/second LAN. Various options are available via a pull-down menuwhich allows the user to change certain functions once connected. If started via the command-line then various options can be input at that stage without the need for making menu selections. In 17

use I found that blocks of pixels sometimes appeared on the screen as a new area was being drawn, but these were erased by the program once the display had finished updating itself. Because of bandwidth restrictions it is obviously not recommended to run programs on the server that constantly move a lot of graphics around (games, for example), but that shouldnt present a problem as that isnt what the program was designed for. It is a remote control and monitoring tool - not a means of remotely playing games.

Sun Microsystems defines J2ME as "a highly optimized Java run-time environment targeting a wide range of consumer products, including pagers, cellular phones, screenphones, digital set-top boxes and car navigation systems." Announced in June 1999 at the Java One Developer Conference, J2ME brings the cross-platform functionality of the Java language to smaller devices, allowing mobile wireless devices to share applications. With J2ME, Sun has adapted the Java platform for consumer products that incorporate or are based on small computing device allowing applications to be dynamically downloaded over a network.


J2ME uses configurations and profiles to customize the Java Runtime Environment (JRE). As a complete JRE, J2ME is comprised of a configuration, which determines the JVM used, and a profile, which defines the application by adding domain-specific classes. The configuration defines the basic run-time environment as a set of core classes and a specific JVM that run on specific types of d


J2ME Benefits on Wireless Devices

Today we take advantage of the second generation of networks and services (2G networks), which use digital networks and web browser technologies. This provides access to data services, but markup languages present some limitations. When Java technology is added to this environment, it brings additional benefits that translate into an enhanced user experience. Instead of plain text applications and latency associated to a browser-based interface, the user is presented with rich animated graphics, a fast interaction, the capability to use an application off-line, and maybe most interestingly, the capability to dynamically download new applications to the device. The challenges that remain the same for Java, WAP, or native APIs is that small screens and limited input interfaces require developers to put some effort into the development of the application user interface.



The configuration defines the basic run-time environment as a set of core classes and a specific JVM that run on specific types of devices. Currently, two configurations exist for J2ME, though others may be defined in the future, CLDC & CDC.


The J2ME CLDC configuration provides for a virtual machine and set of core libraries to be used within an industry-defined profile.. The K virtual machine (KVM), CLDC's reference implementation of a virtual machine, and its KJava profile run on top of CLDC. CLDC outlines the most basic set of libraries and Java virtual machine features required for each implementation of J2ME on highly constrained devices. CLDC targets devices with slow network connections, limited power (often battery operated), 128 KB or more of non-volatile memory, and 32 KB or more of volatile memory.

Two profiles have been defined for J2ME and are built upon CLDC: KJava and MIDP. Both KJava and MIDP are associated with CLDC and smaller devices. Profiles are built on top of configurations. Because profiles are specific to the size of the device (amount of memory) on which an application runs, certain profiles are associated with certain configurations.

A MIDlet is a Java class that extends the javax.microedition.midlet.MIDlet abstract class. It implements the startApp(), pauseApp(), and destroyApp() methods . In addition to the primary MIDlet class that extends javax.microedition.midlet.MIDlet, an MIDP application usually includes other classes, which can be packaged as jar files along with their resources this is known as a MIDlet suite. J2ME WIRELESS TOOLKIT The Wireless Toolkit is an integrated development environment (IDE) for creating Java 2 Platform, Micro Edition (J2ME) applications, commonly referred to as MIDlets. This tutorial will provide step-by-step introductions for downloading, installing, and configuring the toolkit. We'll also walk through the basic steps to compile, preverify, and package MIDlets. To get a better feel for the depth of MIDP 2.0 support, we'll demonstrate the 20

over-the-air provisioning tools to download MIDlets from a remote server. We'll also have a close look at some of the things you can do with the toolkit's security features, such as signing MIDlets, creating certificates, and setting permissions. Finally, we'll briefly cover some of the other features available in the toolkit, including monitoring tools and enhancements to match the MIDP 2.0 spec. The Java Development Kit (JDK) Install the JDK as directed in its accompanying documentation. You can choose the default directory or specify another if you prefer. If you choose to do the latter, make a note of where you install the JDK. During installation of the Wireless Toolkit, the software will attempt to locate the Java Virtual Machine (JVM); if it is unable to do so, you will be prompted for the JDK installation path. The Wireless Toolkit is contained within a single executable file, which you downloaded in the previous panel. Run this file to begin the installation. We suggest that you use the default installation directory. However, if you do not use the suggested directory, make sure the path you select does not include any spaces.

Start the WTK by locating and running KToolbar. You should see a display similar to the figure below.

Let's begin by creating a new project within the WTK. Click the New Project icon. Enter the Project Name and MIDlet Class Name shown in the figure below, then click Create Project to finish this step.


Setting the project properties

One additional step is necessary before we can create the new project: We have to configure the MIDlet attributes. Attributes are divided into six areas;

Required attributes.
There is a total of seven attributes that you must specify when creating a MIDlet suite. These attributes are divided among the JAR manifest file and Java Application Descriptor (JAD) file. For our purpose, clarifying the breakdown of properties within the files is not of importance. One of the benefits of using an IDE is that we can leave the details to the implementation and concentrate our efforts on application development. The WTK creates default values for each attribute, as illustrated in the figure below; we'll use these default values for our MIDlet.


Optional attributes.
These attributes are not required when creating a MIDlet suite; however, they are available if your application has to provide additional information beyond that in the required attributes.

User-defined attributes. As a developer, you can create your own attributes. For
example, as your application evolves, you will more than likely go through many iterations of your JAD file. As such, it may be handy to place a version number inside the file

MIDlet attributes. Here is where we specify attributes for the MIDlet(s) stored in the
suite. By default, the WTK will fill in all the fields for MIDlet-1 based on the Project Name and MIDlet Class Name that we entered when creating the project. To provide for better organization, we'll place the icon for our MIDlet in the images directory. To do that, change the entry for the Icon property to that shown in the figure below. We'll see the icon momentarily.

Push registry attributes. With the release of MIDP 2.0, MIDlets can listen for a
connection from a remote resource; this process is often referred to as pushing data.

Permission attributes. Under the MIDP 1.0 spec, a MIDlet could only access the
libraries (APIs) that were packaged inside the MIDlet suite; this was commonly called the sandbox model. Under this model, a MIDlet could not query information from the device, or otherwise interact outside the scope of the suite. MIDP 2.0 introduces the concept of trusted applications, allowing access beyond the sandbox. In this section, you can add properties to specify which APIs are accessible. Attributes specified in MIDlet-Permissions are those that are required in order for the MIDlet to run. Those specified in MIDletPermissions-opt are optional.


Solaris and Linux support International character converters: You can configure emulated devices to use a variety of character converters. These converters enable you to develop J2ME applications to work with a range of character sets and character encodings. Improved user interface: The graphical user interface has been updated in many areas.


An over-the-sir (OTA) provisioning demo: Emulated devices support network delivery of applications, according to the recommended practice for the Mobile Information Device Profile.

New KToolBar features: One of the features is the ability to use external class libraries. Palm OS Emulator integration: You can use the Palm Os Emulator from Palm, Inc. together with the J2ME Wireless Toolkit to develop applications for the Palm OS devices.

Souce-level debugging: The toolkit enables souce-level debugging of MIDlets within an IDE such as the Forte for Java IDE, using the Java Debugging Wired Protocol (JDWP). This support allows you to more easily inspect your software at runtime and locate sources of bugs.

Command-line interface: The toolkit can be used from a command prompt. Where possible, the toolkit commands use the same command-line syntax as the tools from the Java 2 SDK, Standard Edition. The command-line interface facilities the integration of the J2ME Wireless Toolkit with an IDE.

New emulated devices: Two additional device definitions, for the Motorola i85s telephone and the Research In Motion pager, are included. Although these device definitions resemble real devices, they are not accurate representations of them..

Java Application Manager (JAM): A Java Application Manager (JAM) is a piece of software on a device that, among other things, manages the dynamic download and installation of MIDlets, and provides the interface to their execution on the device. The example JAM included with the toolkit allows you to demonstrate how a user would download, install, and execute an application on a device.

HTTP networking over SSL (HTTPS): MIDlets running in the toolkit can open a secure communication channel with a server using HTTPS. MIDlets using HTTPS and MIDlets using HTTP make the same calls to the HTTP networking APIs; the only difference between them is that a MIDlets using HTTPS uses URLs that begin with https:


Exact compacting garbage collector: The garbage collector in the virtual machine used by the Emulator in the J2ME Wireless Toolkit allows MIDlets to run continuously without risk of fragmenting the memory heap.

Scaled display: This experimental feature allows you to enlarge the image of the emulated device on your screen. The wirelesstoolkit provides the error code

There are three modules for proposed system they are namely Server Connecting Module Desktop Viewer Module Mouse pointer and key access Module


This module is based on authentication where we are provided with IP address and password. If the password does not matches, an alert signal is being given. There are different types of alert signal depending on the connection. At times, due to interruption certain problem is caused. When the password does not match with IP address connection is not established. And proceeding it alert signals are given depending on the type of error in the connection. When the password and IP address matches, the folders are displayed in the mobile.


With the help of VNC server we can view an particular machine after that the desktop will displayed. The currently displayed area of the desktop is called the view port,is the upper_left corner. The functions that are available on the cellular views as basic operations to manipulate the viewport and to send the events.


Panning and zooming:

The user can move the viewport horizontally and vertically.The viewport can be widened(zoom out)to browser its content and narrowed(zoom in)to see the display in greater detail.The viewport shows an area twice as larger as the viewport.


The user can move the pointer on the remote desktop display vertically and horizontally by pressing keys. Dragging can be executed by pressing a key to specify the start of the dragging operation, then moving the pointer, and finally pressing the same key to indicate the end of the dragging operation. When the pointer approaches the edge of the viewport, the viewport is automatically panned to follow the pointer.







s e rve r c o n n c e t io n R e q u e s t (u s in g IP a d d re s )

P C (V N C s e rve r )

A u t h e n t ic a t io n

M o b i le U S E R



D e s k t o p V ie w e r

P ro x y s e rve r

A c c e s s C o n t ro l



Mobile US ER Viewing Desktop Accesing Desktop Connection Request() Key A c cess() Screen Mode()

P roxy Nam e

Convert as Frame() Store The recently A cc ess

VNC server Nam e IP address

Chec k IP A ddress() Transfer Datas() Modified and Store Datas(

Fig 4






C nn ctio R u st o e n eq e C e IP A d ss h ck d re G e Cne n iv n o n ctio R FB


KEY Acce ss

Acce ssin T e D cu e ts g h o mn

Sh td w u o n



Serv er


Mobile USER


Check IP Address Connection True

Connection Requirement

VNC server Start RFB Creating & Open Documents Connection False Refresh CRFB

Desktop View

VNC Proxy

Screen Mode Selection

Mouse Pointer


Key Access

END state

Fig 6




VNC S e rve r

M o b ile USER

C o n n e c t io n E s t a b lis h

A u t h e n t ic a t i o n C o n ve rt F ra m e

P ro x y M o d i fi c a t i o n D o n e

K ey A ccess D e s k t o p V ie w

S t o r e R e c e n t ly A c c e s s In t e r f a c e b / w S e r v e r & U s e r
Fig 7


2: Check IP Address


3: Given Connection 5: CRFB 1: Connection Request 6: KEY Access 7: Accessing The Documents 8: Shutdown


Fig 8




VNC server



Fig 9


We implemented the proposed architecture including the SVNC proxy and the SVNC viewer using Java.


The SVNC proxy was implemented by modifying the Java version of the VNC viewer released by AT&T Laboratories, Cambridge. The proxy runs as a servlet on an HTTP server with the servlet API. We are currently using Apache Tomcat 4.02 as the HTTP server. We have installed the proxy on a PC with a Windows 2000 workstation operating system. The SVNC viewer has been implemented using the J2ME Wireless SDK released by NTT DoCoMo. The code of the SVNC viewer has been placed on the HTTP server of the SVNC proxy and is downloaded in response to requests from the cellular phone. We have tested our viewer using a real cellular phone and have successfully accessed remote computers.

Handshakes in CRFB Protocol

The viewer periodically requests the SVNC proxy to send the desktop display of the remote computer as a frame. This polling action is required to ensure that the Java running on a NTT DoCoMo device follows the definition of Doja3 This definition requires that applications on a cellular phone must explicitly send a request to the proxy to start communication. Moreover, the proxy can only return one message in response to one request from the viewer. For each frame, the viewer sends the position and size of the desired viewport with its zoom level. It should be noted that the proxy can generate a frame by shrinking the original image with anti-aliasing depending upon the zoom level,. Usually, bitmaps transferred from the proxy to the viewer are encoded in 120x130x8 bits with compression. However, during scrolling and dragging, bitmaps are gray-scaled into 120x130x3 bits with compression. Pointing and clicking mouse buttons are achieved by the translation of these events on the proxy side. When the proxy accepts a request from the viewer, it generates corresponding event sequences and sends the sequences to the VNC server. Inputting text is also realized in the same way. For example, when the user inputs the text ls\n, the proxy generates an event sequence consisting of six events; KeyPress(l), KeyRelease(l), KeyPress(s), KeyRelease(s), KeyPress(Return), and KeyRelease(Return). 3Doja is a profile of Connected Limited Device Configuration (CLDC)[11], that is defined by NTT DoCoMo. The bindings of shortcuts are stored in the 34

proxy. When the user assigns an area to a key, the current size and position of the viewport and the zoom level of the viewport are saved. When the user uses a shortcut, the key is sent to the proxy and the proxy sends the viewport information with its image back to the viewer.


Hostcommand.java package tk.wetnet.j2me.vnc; import javax.microedition.lcdui.Command; public class HostCommand extends Command { public HostCommand(String l, int f, int p, int i) { } Ticker.java package tk.wetnet.j2me.vnc; import java.util.TimerTask; class Ticker extends TimerTask { public Ticker(VNCCanvas v) { { } vnc = v; } vnc.tick(); } public void run() private VNCCanvas vnc; super(l, f, p); id = i; } int id;

package tk.wetnet.j2me.vnc; import java.io.*; import java.util.Vector; 35

implements CommandListener, Runnable { protected void incConnectionStatus() { conD++; connectionDisplay.setValue(conD); } public void run() { if(url.getString() == null || url.getString() != null && url.getString().length() < 1) if(host.indexOf(":") >= 0) { try { { host.length())); if(port < 5900) port += 5900; } else { host.length())); } try } incConnectionStatus(); log("Connection Open"); } byte tmp[] = password.getString().getBytes(); incConnectionStatus(); public void commandAction(Command c, Displayable d) { con = (StreamConnection)Connector.open("socket://" + host + ":" + port, 3); port = Integer.parseInt(host.substring(host.indexOf(":") + 2, if(host.charAt(host.indexOf(":") + 1) != ':') port = Integer.parseInt(host.substring(host.indexOf(":") + 1,


if(c == connect)

me.setCurrent(connectingForm); (new Thread(this)).start(); } if(c == add) { try { String tmp = url.getString() + "|" + password.getString(); HostCommand cm = new HostCommand(url.getString(), 8, 10, rs.addRecord(tmp.getBytes(), 0, tmp.length())); hostCmds.addElement(cm); connectionForm.addCommand(cm); } if(c == manage) { Form manageForm = new Form("Manage Hosts"); hosts = new ChoiceGroup("Host:", 1); try { int size = hostCmds.size(); } if(c == delete) { String removes = hosts.getString(hosts.getSelectedIndex()); int remove = Integer.parseInt(removes.substring(0, removes.indexOf(" "))); hosts.delete(hosts.getSelectedIndex()); try { rs.deleteRecord(remove); } catch(Throwable t)


for(int i = hostCmds.size() - 1; i >= 0; i } try { if(c1.getResponseCode() != 200) { s = c1.getResponseCode() + " : " + c1.getResponseMessage(); } else { int len = (int)c1.getLength(); { int ch; for(s = new String(); (ch = is.read()) != -1; s = s + (char)ch); } } } if(os != null) try { os.close(); } catch(Exception e1) { } if(c != null) try { c1.close(); } catch(Exception e1) { } if(is != null) try {


is.close(); } if(c != null) try { c1.close(); } catch(Exception e1) { } if(c == back) me.setCurrent(connectionForm); else } public VNC() { rs = null; options = null; hostCmds = new Vector(); log = new Command("Log", 4, 0); uploadLog = new Command("Upload", 4, 0); backLog = new Command("Back", 4, 0); backDisplayable = null; connectionForm = new Form("VNC"); connectingForm = new Form("VNC - Connecting"); url = new TextField("Host", "", 25, 0); setProxy = new Command("Set HTTP Proxy", 8, 2); hosts = null; host = ""; port = 5900; httpProxy = new TextBox("HTTP Proxy:", "", 255, 4); connectionDisplay = new Gauge("Connecting", false, 5, 0); shared = new ChoiceGroup("", 2);


conD = 0; aboutImage = null; rid = 0; me = Display.getDisplay(this); shared.append("Share Desktop", null); shared.append("NCM", null); shared.append("Use HTTP Proxy", null); try { rs = RecordStore.openRecordStore("hosts", true); RecordEnumeration re; HostCommand cm; for(re = rs.enumerateRecords(null, null, false); re.hasNextElement(); hostCmds.addElement(cm)) { int id = re.nextRecordId(); String current = new String(rs.getRecord(id)); String title = current; if(current.indexOf("|") > 0) title = current.substring(0, current.indexOf("|")); cm = new HostCommand(title, 8, 10, id); } options = RecordStore.openRecordStore("options", true); re = options.enumerateRecords(null, null, false); if(re.hasNextElement()) { rid = re.nextRecordId(); byte opts[] = options.getRecord(rid); if(opts != null && opts.length > 0) { shared.setSelectedIndex(0, (opts[0] & 1) == 1);


shared.setSelectedIndex(1, (opts[0] & 2) == 2); if(opts.length > 1) httpProxy.setString(new String(opts, 1, opts.length - 1)); } } else { rid = -100; } aboutImage = Image.createImage("/VNC.png"); connectingForm.setCommandListener(this); connectingForm.append(aboutImage); connectingForm.append(connectionDisplay); } catch(Throwable t) { System.err.println("VNC() : t " + t.toString()); t.printStackTrace(); } } protected void destroyApp(boolean parm1) throws MIDletStateChangeException { System.out.println(b[0]); if(rid != -100) { options.setRecord(rid, b, 0, b.length); System.out.println("hi"); } else { options.addRecord(b, 0, b.length); }


rs.closeRecordStore(); options.closeRecordStore(); } private RecordStore options; private Vector hostCmds; protected Display me; protected VNCCanvas canvas; protected RFBProto rfb; private StreamConnection con; private Thread run; Command log; Exception e; private Command uploadLog; case 67: // 'C' send = 65481; break; case 111: // 'o' default: send = s.charAt(i); break; } } switch(cmd) { case 33: // '!' midlet.rfb.key(send, true); midlet.rfb.key(send, false); break; case 60: // '<' midlet.rfb.key(send, true); break;


} } else if(s.charAt(i) == 'm') { VNC.log("Move Move: Going: " + s); mouseX = Integer.parseInt(s.substring(i + 1, i + 5)); VNC.log("Move Move: mouseY: " + s.substring(i + 6, i + 10)); if(mouseX > midlet.rfb.y) mouseX = midlet.rfb.y; VNC.log("Move Move: " + mouseX + "x" + mouseY); midlet.rfb.mouse(mouseX, mouseY, 0); i = 9; } else if(s.charAt(i) == 'M') { VNC.log("Move Screen: Going: " + s); int mX = Integer.parseInt(s.substring(i + 1, i + 5)); VNC.log("Move Screen: " + mX + "x" + mY); incUpdate = false; offx = mX; offy = mY; i = 9; } else } private VNC midlet; private Timer timer; private boolean ctrl; private String viewModes[] = { "Normal", "Full Screen" }; private String inputModes[] = {


"Navigation", "Mouse Mode" }; private char keys[][] = { { '*' } }; private int divx; private int divy; }

package tk.wetnet.j2me.httpsocket; import java.io.*; import javax.microedition.io.*; import tk.wetnet.util.Queue; public class HTTPSocket extends InputStream implements StreamConnection { pc = 0; length = 0; buffer = new byte[255]; this.host = host; this.proxy = proxy; outputs.push(new OutputQueueEntry()); } private void request() throws IOException { HttpConnection c = (HttpConnection)Connector.open(proxy + "?t=" + ticket + "&G=255"); HttpConnection _tmp = c;


c.close(); } public void close() throws IOException { if(closed) { throw new IOException("Closed Stream"); } else { closed = true; return; } } private boolean closed; private OutputStream os; public String proxy; private String ticket; }

package tk.wetnet.vnc; public class DesCipher { public DesCipher(byte key[]) { encryptKeys = new int[32]; decryptKeys = new int[32]; tempInts = new int[2]; setKey(key); }


public static void squashBytesToInts(byte inBytes[], int inOff, int outInts[], int outOff, int intLen) } }; private static int SP1[] = { 0x1010400, 0, 0x10000, 0x1010404, 0x1010004, 0x10404, 4, 0x10000, 0x10404, 0x1000000, 0x10000, 0x1010404, 4, 0x1010000, 0x1010400, 0x1000000, 0x1000000, 1024, 0x1010004, 0x10000, 0x10400, 0x1000004, 1024, 4, 0x1000404, 0x10404, 0x1010404, 0x10004, 0x1010000, 0x1000404, 0x1000004, 1028, 0x10404, 0x1010400, 1028, 0x1000400, 0x1000400, 0, 0x10004, 0x10400, 0, 0x1010004 };

package tk.wetnet.vnc; import java.io.DataInputStream; import java.io.OutputStream; import tk.wetnet.j2me.vnc.VNC; import tk.wetnet.util.Queue; public class RFBProto implements Runnable { private class Event extends tk.wetnet.util.Queue.QueueEntry { private byte buffer[]; private int size; private int pc; private Event() { buffer = new byte[10]; size = 0;


pc = 0; } } switch(c) { case 1: // '\001' VNC.log("NO_AUTH"); break; case 2: // '\002' VNC.log("NORMAL_AUTH"); byte fc[] = new byte[16]; sout.write(fc); sout.flush(); int authResult = readCard32(); break; default: byte reason[] = new byte[readCard32()]; readFully(reason); String string = new String(reason); VNC.log("Connection Refused\n" + string); drawOnMe.error("Connection Refused\n" + string); return false; } } private int readCard8() throws Throwable { return (byte)sin.read() & 0xff; } private int returnDataExpected; private Queue eventQueue;


public volatile boolean running; private Thread me; private static final int AS_SUB_ENCODING = 8; private static final int SC_SUB_ENCODING = 16; }


The first test in the development process is the unit test. The source code is normally divided into modules, which in turn are divided into smaller units called units. These units have specific behavior. The test done on these units of code is called unit test.In this project the unit test will be performed on VNC and server connecting Module. Unit tests ensure that each unique path of the project performs accurately to the documented specifications and contains clearly defined inputs and expected results.


Several modules constitute a project. If the project is long-term project, several developers write the modules. Once all the modules are integrated, several errors may arise. The testing done at this stage is called system test. System testing ensures that the entire integrated software system meets requirements. It tests a configuration to ensure known and predictable results. System testing is based on process descriptions and flows, emphasizing pre-driven process links and integration points.


The process of exercising software with the intent of ensuring that the software system meets its requirements and user expectations and doesn' fail in an unacceptable manner. The individual or group doing this work is not part of the group or organization that developed the software. A term often applied to government work or where the government regulates the products, as in medical devices.



Testing two or more modules or functions together with the intent of finding interface defects between the modules or functions. In our Project server connection,desktop viewer and mouse pointer will be Integrated to VNC Module. Testing completed at as a part of unit or functional testing, and sometimes, becomes its own standalone test phase. On a larger level, integration testing can involve a putting together of groups of modules and functions with the goal of completing and verifying that the system meets the system requirements.













VNC is a very impressive product, especially considering that its free. Quite apart from that, its main advantage over its commercial competitors is that it is open source, so anyone with programming skills can contribute towards it and so make it an even better, more flexible product. Even in its current form, its remote control applications are almost limitless, and it will no doubt find many uses and supporters in a typical support environment. This project is designed as per the current requirement to the industry. Using this project we can view the remote desktop using a mobile with GPRS connectivity.

We have proposed a system to remotely access a computer desktop using only a cellular phone, despite the physical and bandwidth limitations of cellular phones. The system has a VNC-based architecture for accessing a remote desktop from the cellular phone. A proxy is placed to convert different devices, to suppress network traffic, and to support recovery from an unscheduled disconnection. To increase user-friendliness and to solve the problem of the small screen, several functions are provided on the cellular viewer. Frequently used screen areas of the desktop can be registered and quickly restored quickly by using a Shortcut assignment. The Guidance function can be used to show the Shortcut assignments. Two areas of the desktop display can be viewed simultaneously using the Twin view function. We have implemented a prototype of this system using Java, and checked the operation on a Java-enabled cellular phone emulator. Currently, we are extending our implementation to support incremental updating of the SVNC viewer image, to speed up the frame rate and to incorporate more intelligent navigation. We are also trying to provide integrated panning and zooming of the viewport to simplify these basic operations, by applying speed-dependent automatic zooming.


8. BIBILOGRAPHY [1] http:/www.sun.com.java/j2me [2] http:/www.sun.com.java [3] http:/www.sun.com/j2me/toolkit [4] James Keogh, Complete Reference J2ME, TataMcGraw-Hill,2004, New Delhi. [5] www.iplab.cs.tukuba.ac.jp/~shizuki/r/papers/svnc-csn2002.pdf.