A Smartphone Application to Remotely Access a PC over the Internet

A project report submitted in partial fulfilment of the requirements for the award of the Degree of

in Computer Science & Engineering under the guidance of Mr. K. A. Abdul Nazeer by Faiz Abdullah Y2.188 Hari S. Y2.042 Shijith T.R. Y2.091

Department of Computer Engineering NATIONAL INSTITUTE OF TECHNOLOGY CALICUT Kerala - 673601 April 2006

Certificate

This is to certify that the project entitled “A Smartphone Application to remotely access a PC over the Internet” is a bonafide record of the project done by Faiz Abdullah, (Y2188), Hari S. (Y2.042) and Shijith T.R. (Y2.091) under our supervision and guidance. The project report has been submitted to the Department of Computer Engineering of National Institute of Technology Calicut in partial fulfilment of the award of the Degree of Bachelor of Technology in Computer Science and Engineering

Dr. M. P. Sebastian Professor and Head Dept. of Computer Engineering NIT Calicut

Mr. K. A. Abdul Nazeer Project Guide Senior Lecturer Dept. of Computer Engineering NIT Calicut

Abstract

A Smartphone is a device that can take care of all of our handheld computing and communication needs in a single, small package. Unlike many traditional cell phones, Smartphones allow individual users to install, configure and run applications of their choice. A Smartphone offers the ability to conform the device to our particular way of doing things. Most standard cell-phone software offers only limited options for reconfiguration, forcing us to adapt to the way it is set up. On a standard phone, whether or not we like the built-in calendar application, we are stuck with it except for a few minor tweaks. If that phone were a Smartphone, we could install any compatible calendar application we like.

This project aims to develop a Windows CE application for Windows powered Smartphone running Smartphone 2002 operating system. The application will enable the Smartphone user to access a PC remotely enabling the user to start a shell and execute commands like, up2date, for updating packages on the PC via the internet, fsck to run scan disk etc., send messages to users logged on to the same network to which the PC is connected and possibly retrieve or backup data over the Internet. The user can also execute the command halt to finally switch off the PC. All this is made possible via GPRS connection on the phone running a client program and the PC connected to the Internet running the corresponding server program which includes the shell interpreter as well as a dynamic DNS client.

Acknowledgements

We are deeply indebted to our project guide, Mr. K. A. Abdul Nazeer Senior Lecturer, Computer Engineering Department, NIT Calicut and our friends for their valuable guidance & suggestions in successfully completing our project.

Faiz Abdullah Hari S. Shijith T. R.

Contents

Chapters 1. Introduction 1.1. 1.2. Motivation Problem Specification …1 …1 …2 …3 …3 …3 …3 …4 …4 …5 …5 …5 …6 …7 …7 …7 …8 …9 …9

2. System Analysis 2.1. Literature Survey 2.1.1. Windows® CE 2.1.2. Windows® CE – Modules and Components 2.1.3. The Language – eMbedded Visual C++® 2.1.4. The Windows® CE Programming Model 2.2. 2.3. 2.4. 2.5. Working with the Smartphone 2002 emulator Managing Communications with the Emulator ActiveSync Transport TCP/IP Transport

3. System Design 3.1. 3.2. 3.3. 3.4. 3.5. Assumptions made Original Scenario Present Scenario Alternative Scenario Pseudo terminals

4. Implementation 4.1. Shell 4.2. Smartphone GUI and Client program 4.3. Results 4.3.1. Screenshots 5. Testing 5.1. Connecting to the PC 5.2. Executing Commands 5.3. Displaying the output 6. Conclusion 6.1. Summary 6.2. Future Work Bibliography

…10 …10 …11 …12 …12 …13 …13 …13 …13 …14 …14 …14 …15

Figures

Figure 3.1: Desktop establishes the active connection 3.2: Smartphone establishes the active connection 3.3: Both the Smartphone and PC are clients 4.1: Input Screen 4.2: Output Screen 4.3: (a) Input Screen for ‘ls’ (b) Output screen for ‘ls’ (c) Input screen for ‘cat’ (d) Output screen for ‘cat’ (e) Input screen for ‘du’ (f) Output screen for ‘du’ …7 …8 …9 …11 …11 …12 …12 …12 …12 …12 …12

1

Chapter 1

INTRODUCTION

The dominance of traditional cell phones has begun to reduce and they are gradually being replaced by powerful Smartphones, which allow us to install, run and configure applications of our choice. For the programmer, this opens up a new area of application development with new challenges, i.e. small display screens and limited hardware capabilities. With the help of freely available application development tools, we embarked upon developing a Smartphone application to remotely access a PC.

1.1

Motivation

There are times when we are away from our desktop PC back home and would like to start some maintenance or update programs especially when we are unexpectedly delayed or we urgently require a file from our PC having forgotten it in our system back home or the removable media containing the copy of the file we possess fails when needed. This project aims to resolve such issues. Smartphones are going to dominate the next generation of mobile phones. Hence we decided to develop an application for the Smartphone to remotely access a PC and possibly retrieve files from the PC.

2

1.2

Problem Specification

The application will be developed using Microsoft® eMbedded Visual C++® 3.0 and Microsoft® Smartphone SDK 2002. The main part of this project involves establishing a wireless connection between the Smartphone and PC. Once this connection is established, it should enable the Smartphone user to access one’s own PC remotely, to start a shell to control the PC, open various programs for system maintenance, to retrieve necessary files from the PC, to backup files from the Smartphone on to the PC and finally switch off the PC.

3

Chapter 2

SYSTEM ANALYSIS

2.1
2.1.1

Literature Survey
Windows® CE

Microsoft® Windows® CE is an open, scalable, 32-bit operating system (OS) that is designed to meet the needs of a broad range of intelligent devices, from enterprise tools such as industrial controllers, communications hubs, and point-of-sale terminals to consumer products such as cameras, telephones, and home entertainment devices. A typical Windows® CE-based eMbedded system targeted for a specific use [1], often runs disconnected from other computers, and requires an operating system that has a small footprint and a built-in deterministic response to interrupts. Windows® CE offers the application developer the familiar environment of the Microsoft® Win32® application programming interface (API), ActiveX controls, message queuing (MSMQ) and Component Object Model (COM) interfaces, Active Template Library (ATL), and the Microsoft® Foundation Classes (MFC) Library. ActiveSync provides easy connectivity between the desktop and the eMbedded device, whether by serial connection, infrared port, or network cable. There is built-in support for multimedia (including DirectX), communications (TCP/IP, SNMP, TAPI, and more), and security. 2.1.2 Windows® CE - Modules and Components

Since minimization of memory requirements is a major design goal, Windows® CE is built from a set of discrete modules and sub modules, or components. Each of these

4

modules provides full or partial support for major features of the operating system, and can be tailored to the needs of a given eMbedded application. By selecting a minimum set of modules and components, a device manufacturer can control the size (“footprint”) of the operating system software while still providing the richest possible set of APIs for developing applications and the performance of 32-bit, preemptive multitasking, multithreaded system. 2.1.3 The Language – eMbedded visual C++®

Microsoft® eMbedded Visual C++® provides an Integrated Development Environment (IDE) designed for developing applications for Windows® CE devices. It consists of an integrated set of windows, tools, menus, toolbars, directories, and other elements to help create, test, and debug a Windows® CE application. 2.1.4 The Windows® CE Programming Model

The Windows® CE operating system is based on the Win32 application programming interface (API). The fundamentals of programming for Windows® CE are closely parallel to programming for Windows® 98, Windows® NT, and Windows® 2000. As with the other Windows® operating systems, Windows® CE is an event-driven programming model [5]. A Windows® CE-based program receives messages, interprets the messages, and acts on the messages. A Windows® CE program has one or more windows that receive and process messages in a message loop. The windows can be visual or, for an application that does not require a user interface, nonvisible. Each window has a window handle (hwnd) associated with a message processor that handles the messages for the window. You can also use the window handle to call any related function. Like any other Windows-based program, a Windows® CE program has two primary functions, a message processor (usually called WndProc) and WndMain, which provides an entry point to the program. The WndProc function processes messages for the Window. In general, an application processes only those messages that are

5

relevant to it, and passes other messages back to the operating system. In addition to being the primary message process for an application, WinMain also handles initialization and shutdown.

2.2

Working with the Smartphone 2002 Emulator

The Software Development Kit (SDK) for the Microsoft® Windows® Powered Smartphone 2002 includes a new emulation environment. This environment provides a virtual computer running Smartphone 2002 software compiled for the Intel x86 processor. The virtual computer duplicates hardware that runs Microsoft® Windows® CE on an x86-based PC.

2.3

Managing Communications with the Emulator

Platform Manager is the component that manages the communications between a development tool and a real or emulated Smartphone device. Platform Manager allows the tool to connect to the device and download files to it, and supports application-level debugging. Platform Manager abstracts the differences between various connection mechanisms; for example, Microsoft® ActiveSync® and TCP/IP. The Platform Manager Transport manages the details of physical communication to the device. The Platform Manager Startup Server manages the details of downloading code to the device and starting applications on the device side.

2.4

ActiveSync Transport

Microsoft® ActiveSync® transport creates an application-level connection to a target device that runs on top of the connection provided by ActiveSync. ActiveSync is a connectivity application that runs on a desktop computer and facilitates connections with a target device. ActiveSync technology provides data replication and synchronization by comparing the data on the target device with the data on the desktop computer to identify the most recent information.

6

ActiveSync transport is not used with the emulator, but can be used with a real Smartphone 2002 device. ActiveSync transport represents the most basic level of connectivity between a device and the tools through Platform Manager.

2.5

TCP/IP Transport

TCP/IP transport uses the TCP/IP protocol for communication between the host computer and the target device over an Ethernet connection. TCP/IP is the basic communications protocol of the Internet. Many developers also use it as a communications protocol for private networks, such as intranets and extranets. TCP/IP is much faster than ActiveSync when we use it with Smartphone 2002 devices that have a network card. When we use the emulator, the TCP/IP transport is the only supported connectivity.

7

Chapter 3

SYSTEM DESIGN

3.1

Assumptions made
The PC has Modem Ring on feature which allows us to switch on the PC remotely from off state using the Smartphone. • The PC can establish a connection to the Internet using a modem or broadband. • The Smartphone can establish a connection to the Internet using GPRS.

3.2

Original Scenario

The Smartphone will connect to the Internet using a GPRS connection. The Smartphone will be assigned an IP address enabling it to be accessed from any system over the Internet. Once the PC has established a connection to the Internet it will establish a connection with the Smartphone and exchange messages.

Smartphone

NAT

Internet Server

PC

Fig.3.1: Desktop establishes the active connection

8

However, reading the details of GPRS connectivity revealed that the Public Land Mobile Network (PLMN) assigns the Smartphone a private address that is part of the PLMN operator’s private network and is not accessible from the public network [2]. A NAT sits in between the public and private network and may be using a firewall. Hence the PC cannot actively open a connection with the Smartphone. Only the Smartphone can establish an active connection.

3.3

Present Scenario

Once the PC connects to the Internet it will be assigned a public IP address. While using a dial-up or broadband connection we lease the IP via DHCP from the DHCP server of the ISP. Hence the IP of the computer is not static and varies with each connection. The mobile is unable to find out the IP of the PC when it is at the remote location. To solve this problem there exist a mechanism known as Dynamic DNS (DDNS). The DDNS server maps domain names to IP addresses. It maintains a database of domain names and IP addresses and whenever a DNS request is received, the IP address of the corresponding PC is returned. When the PC connects to the Internet it updates its IP address in the database of the DDNS using a DDNS client installed on the PC. Since the domain name of the PC always remains the same, the Smartphone can establish an active connection with the PC indicated by its domain name.

Smartphone

NAT

Internet Server

PC

Fig.3.2: Smartphone establishes the active connection

9

3.4

Alternative Scenario

This design does not make use of DDNS and overcomes any difficulties associated with NAT. Both the Smartphone and the PC are considered to be clients initiating a connection with another PC which has a public IP address assigned with it, which essentially acts as a public server. The server is hosted in the public PC and enables transfer of messages between the PC and the Smartphone. However, a major drawback of this design is the difficulty in finding a PC having a public IP. Also in this design the server would have to redirect all the input (commands from the side of the Smartphone) to the PC and vice versa. Being a public server, such functionality may not be provided.

Public Server

Smartphone

NAT

Internet Server

PC

Fig. 3.3: Both the Smartphone and PC are clients

3.5

Pseudo terminals

Pseudo terminals are very similar to pipes and other ‘System V’ Inter Process Communication (IPC) that simulates a terminal [4]. A Pseudo terminal has got two sides- a master side and a slave side. The master side is controlled by a single process while the slave side is read & written by several processes.

10

Chapter 4

Implementation

4.1

Shell

The process running on the PC acquires a pseudo terminal pair and then the fork system call is used to create a child. At the parent we close the slave side of the pseudo terminal. At the child we close the master of the pseudo terminal. Thus we have got the communication channel set up. The child now sets the slave of the pseudo terminal as the standard input, output and error device. It then execs the bash shell. Hence, whatever is entered at the master side is transmitted to the slave side and is taken as input and the resulting output (or error) is printed into the slave side, which is eventually read by the master. The Smartphone establishes a connection with the parent and then the parent gets whatever is typed from the Smartphone and writes it into the master side of the pseudo terminal. Later it reads the master to see what the output is and relays it to the Smartphone. The initial shell developed was able to handle only single line commands. It was developed on a Linux host and was tested in Linux alone without communicating with the Smartphone emulator/device. It was unable to handle character by character transfer of commands. It was also unable to handle signals. Later, we managed to implement the above two capabilities. The terminal input is usually line buffered, but this does not serve our purpose. We need to have unbuffered

11

transmission of data in order to achieve character by character transmission of data to the shell. Hence the terminal was appropriately initialized for this purpose. In order to implement character by character transmission via sockets, we need to flush data as soon as a character is received at the client side. Usually sockets are opened as a descriptor [3]. But this would not serve the purpose. Hence we decided to open it as a file pointer, which enables us to flush data as soon as it is entered on the client side. As far as signals were concerned, we assumed that if we transmit a ‘signal’ to bash, it will kill the process. For example, we need to pass the signal ‘Control C’ (^C) in order to stop a ping process which continues indefinitely once executed, unlike in Windows®. In order to make this work, a “CtrlC” entered on the client (i.e. the phone) is interpreted to its ASCII value and sent to the master side of the shell. Now the master side will send a SIGINT corresponding to “CtrlC” to the slave side of the shell. On receiving the SIGINT signal, the process running on the server stops.

4.2

Smartphone GUI and Client program

The Smartphone GUI was developed using Microsoft® eMbedded Visual C++® 3.0 as shown below. The output is displayed in a message box supporting vertical scroll and word wrap features. Horizontal scroll was not preferred considering the usability of a Smartphone.

Fig.4.1: Input Screen

Fig.4.2: Output Screen

The client program, also developed using Microsoft® eMbedded Visual C++® 3.0. As usual the client creates a socket, binds a port to the socket, and then connects to

12

the remote PC by using the host name of the PC. The hostname we have chosen is mapped to the public IP of the PC with the help of DDNS as explained above in the section “3.3 Present Scenario”.

4.3

Results

A shell was developed on the Linux platform for interpreting the commands entered on the Smartphone and to send the corresponding output back to the Smartphone. An appropriate GUI was developed for the Smartphone for entering the commands and displaying the output. Almost all commands could be executed to a high level of satisfaction considering the limitations imposed on us due to the display size of the Smartphone as well as its keypad. 4.3.1 Screenshots

The following screenshots show the input and output screens for various commands executed on the Smartphone.

(a)

(c)

(e)

(b)

(d)

(f)

Fig.4.3: (a) Input Screen for ‘ls’, (b) Output screen for ‘ls’, (c) Input screen for ‘cat’, (d) Output screen for ‘cat’, (e) Input screen for ‘du’, (f) Output screen for ‘du’

13

Chapter 5

Testing

Before testing the application, we must ensure that the PC is connected to the internet using a dial up or broadband connection. After establishing the connection, it must update its leased public IP at the DDNS server using the DDNS client. Further, the server specific program must be running.

5.1

Connecting to the PC

First, the Smartphone must connect to the internet using GPRS. Then on executing the Smartphone application, it opens a connection with the PC and displays the GUI for entering various commands.

5.2

Executing commands

The commands, ls, ps, du, cat, top, ping and vi were tested. All of them worked successfully and displayed the output. Although, while using vi, it is not possible to view the vi screen under the current functionality of the application. Signals ‘CtrlC’ and ‘CtrlD’ were also tested to stop programs like ping and top. To send commands without appending a newline character (“\n”), like ‘q’ to exit a UNIX ‘man’ page, we press the “no \n” button instead of the “Submit” button. All the above mentioned commands executed successfully.

5.3

Displaying the output

The output displayed correctly in the message box. At times we experienced a considerable delay in receiving the output because of network congestion. Further to read the next set of data in the socket, the “Read” button was used and to remove unnecessary data from the socket (if the size of the previous output is larger than the buffer), the “Flush” button was used. These features worked successfully.

14

Chapter 6

Conclusion

6.1

Summary

A Smartphone is more than just a powerful phone that can be personalised to suit ones needs and fancy. It is a revolutionary handheld computing device in itself. Through this project we were able to show that it is possible to control PCs wirelessly. In fact, the application can control the PC from any part of the world. This is an important area of research in the digital world and a lot of work is being done to develop new as well as better approaches and technologies for remote handheld computing.

6.2

Future Work
Developing an FTP client for the Smartphone would be highly appreciated because it would allow for remote retrieval and back up of data between the Smartphone and PC. • • An authentication mechanism must be developed to prevent unauthorized access to the remote PC. The GUI can be improved by adding a suitable command bar integrating the buttons on the first screen of the current application. The rest of the screen could show the output.

15

Bibliography

[1] Microsoft® Developer Network Library, http://msdn.microsoft.com/mobility [2] “Guidelines for IPv4 Addressing and AS Numbering for GPRS Network Infrastructure and Mobile Terminals.” GSM Association, PRD: IR.40, September 2001. [3] Stevens, R. UNIX Network Programming: Sockets & XTI. Vol. 1, 2 edition, 2001. [4] Stevens, R. UNIX Network Programming: Inter Process Communications. Vol. 2, 2 edition, 2001. [5] Boling, D. Programming Microsoft® Windows® CE. Microsoft® Press, 2nd Edition, 2001.

Sign up to vote on this title
UsefulNot useful