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, (Y2-

188), 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 re-

configuration, 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. Motivation …1

1.2. Problem Specification …2

2. System Analysis …3

2.1. Literature Survey …3

2.1.1. Windows® CE …3

2.1.2. Windows® CE – Modules and Components …3

2.1.3. The Language – eMbedded Visual C++® …4

2.1.4. The Windows® CE Programming Model …4

2.2. Working with the Smartphone 2002 emulator …5

2.3. Managing Communications with the Emulator …5

2.4. ActiveSync Transport …5

2.5. TCP/IP Transport …6

3. System Design …7

3.1. Assumptions made …7

3.2. Original Scenario …7

3.3. Present Scenario …8

3.4. Alternative Scenario …9

3.5. Pseudo terminals …9

4. Implementation …10

4.1. Shell …10

4.2. Smartphone GUI and Client program …11

4.3. Results …12

4.3.1. Screenshots …12

5. Testing …13

5.1. Connecting to the PC …13

5.2. Executing Commands …13

5.3. Displaying the output …13

6. Conclusion …14

6.1. Summary …14

6.2. Future Work …14

Bibliography …15

Figures

Figure

3.1: Desktop establishes the active connection …7

3.2: Smartphone establishes the active connection …8

3.3: Both the Smartphone and PC are clients …9

4.1: Input Screen …11

4.2: Output Screen …11

4.3: (a) Input Screen for ‘ls’ …12

(b) Output screen for ‘ls’ …12

(c) Input screen for ‘cat’ …12

(d) Output screen for ‘cat’ …12

(e) Input screen for ‘du’ …12

(f) Output screen for ‘du’ …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 Literature Survey 2.1.1 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.

C e

Fig.3.1:

NAT

Smartphon

Desktop establishes the active connection

P

Internet Server

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.

Internet Server PC NAT

Smartphone

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

Internet Server PC NAT

Smartphone

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.