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 Mr. K. A. Abdul Nazeer

Professor and Head Project Guide
Dept. of Computer Engineering Senior Lecturer
NIT Calicut 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.

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.