Remote Controlled Electronic Switching System

Project Report
Parlikar Alok Ulhas Nishant Shrivastava
Shubham Shrestha Agrwal Varun Khullar
Project Guide: Dr. G. C. Nandi
Indian Institute of Information Technology, Allahabad
Report prepared with LATEX.
Abstract
We propose to install a system that shall enable an electronic switching device
interfaced with a computer to be controlled remotely using a smart device. A
client running on the user's computer would connect to a central server, over
an Internet connection. The user could then use a HTTP/WAP protocol from
a smart device to connect to the central server, and issue requests to control his
device.
In this report we describe happyRC.NET { the set of software and hardware
setup that helps in addressing to the problem we have identi_ed. We explain the
methodology that this system has adopted to tackle the issue. We also explain
the security considerations that we have focused on while designing the custom
client server protocols. In the end, we conclude with possible enhancements
in the project that might take us to a whole new world of remotely operated
gadgets in every home.
Acknowledgment
The authors gratefully acknowledge the guidance provided by the project supervisor
Dr G. C. Nandi throughout the development of the project.
The authors also wish to thank the other faculty members for their valuable
suggestions and directions.
The authors also thank their batch mates for providing constant encouragement,
support and valuable suggestions during the development of the project.
i
Candidate's Declaration
We hereby declare that this project report titled `happyRC.NET Remote Controlled
Electronic Switching System' submitted towards the completion of Mini
Project in 5th semester of B.Tech(I.T.) in Indian Institute of Information Technology,
Allahabad is an authentic record of our work carried out under the
guidance of Dr. G. C. Nandi, Dean(Academics), IIIT Allahabad.
Date: December 3, 2004
Place: Allahabad
Parlikar Alok Ulhas Nishant Shrivastava
Shubham Shrestha Agrwal Varun Khullar
Certi_cate
This is to certify that the above declaration made by Mr. Nishant Shrivastava,
Mr. Parlikar Alok Ulhas, Mr. Shubham Shrestha Agrwal and Mr. Varun Khullar
is true to the best of my knowledge and belief.
Date: December 3, 2004
Place: Allahabad
Dr. G. C. Nandi
Dean (Academics)
Indian Institute of Information Technology, Allahabad
ii

Contents
1 Introduction 1
1.1 What the problem is . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Importance of the problem . . . . . . . . . . . . . . . . . . . . . 2
2 State of the Art 3
3 System Architecture 4
3.1 ESS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.2 CSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.3 Smart Device Client . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.4 Architecture Notes . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4 How happyRC.NET works 7
4.1 Registering New User . . . . . . . . . . . . . . . . . . . . . . . . 7
4.2 Activating Remote Device . . . . . . . . . . . . . . . . . . . . . . 7
4.3 Showing Device State Change Interface . . . . . . . . . . . . . . 7
4.4 Calculating New State Numbers . . . . . . . . . . . . . . . . . . 7
4.5 Changing the State . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.6 Logging O_ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.7 Overall Activity Flow . . . . . . . . . . . . . . . . . . . . . . . . 8
5 Design Issues 11
5.1 ESS Client Design . . . . . . . . . . . . . . . . . . . . . . . . . . 11
5.2 CSS Server Design . . . . . . . . . . . . . . . . . . . . . . . . . . 13
5.3 WebService Design . . . . . . . . . . . . . . . . . . . . . . . . . . 13
6 Speci_c Technologies used 15
6.1 .NET Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
6.1.1 The Common Language Runtime . . . . . . . . . . . . . . 16
6.2 .NET Remoting . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
7 Conclusion and Future Scope 18
A User Manuals 19
A.1 Manual for the ESS Client . . . . . . . . . . . . . . . . . . . . . . 19
A.1.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 19
A.1.2 Installing the Application . . . . . . . . . . . . . . . . . . 19
A.1.3 Using the Program . . . . . . . . . . . . . . . . . . . . . . 21
A.2 Manual for the CSS Server . . . . . . . . . . . . . . . . . . . . . 24
iii
A.2.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 24
A.2.2 Using the Program . . . . . . . . . . . . . . . . . . . . . . 24
A.3 Manual for the CSS Webservice . . . . . . . . . . . . . . . . . . . 26
B Hardware Details 28
C CSS-ESS Protocol Details 29
C.1 Getting Connected . . . . . . . . . . . . . . . . . . . . . . . . . . 29
C.2 Security Paranoia and Encryption . . . . . . . . . . . . . . . . . 29
C.2.1 Two Types of Cryptography . . . . . . . . . . . . . . . . 29
C.2.2 Security Attacks . . . . . . . . . . . . . . . . . . . . . . . 30
C.2.3 Security Solution in happyRC.NET . . . . . . . . . . . . 30
C.3 The Request Reply Protocol . . . . . . . . . . . . . . . . . . . . . 31
C.3.1 Key Transfer . . . . . . . . . . . . . . . . . . . . . . . . . 31
C.3.2 Client Authentication . . . . . . . . . . . . . . . . . . . . 31
C.3.3 Getting the Device Details . . . . . . . . . . . . . . . . . 32
C.3.4 Commanding the ESS . . . . . . . . . . . . . . . . . . . . 32
C.3.5 Logging O_ . . . . . . . . . . . . . . . . . . . . . . . . . . 32
C.3.6 Exceptional Messages . . . . . . . . . . . . . . . . . . . . 33
C.4 Protocol at a glance . . . . . . . . . . . . . . . . . . . . . . . . . 33
D Device Con_guration File Format 34
E Developer Details { Writing a client for CSS 36
Bibliography 37
iv
List of Figures
3.1 Architecture of the overall System . . . . . . . . . . . . . . . . . 4
4.1 Overall Activity Flow Diagram . . . . . . . . . . . . . . . . . . . 9
A.1 Installation of .NET Framework 2.0 . . . . . . . . . . . . . . . . 20
A.2 ESS Client Installation Requirements Veri_cation . . . . . . . . . 20
A.3 ESS Client Installation Security Warning . . . . . . . . . . . . . 21
A.4 ESS Application Login Screen . . . . . . . . . . . . . . . . . . . . 21
A.5 ESS Application Settings Dialogue . . . . . . . . . . . . . . . . . 22
A.6 ESS Application { User Logged In . . . . . . . . . . . . . . . . . 23
A.7 ESS Application { Change Password . . . . . . . . . . . . . . . . 24
A.8 CSS Login Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
A.9 Administration Tasks on the CSS . . . . . . . . . . . . . . . . . . 26
A.10 Smart Device: Logging in . . . . . . . . . . . . . . . . . . . . . . 26
A.11 Smart Device: Authentication Process . . . . . . . . . . . . . . . 27
A.12 Smart Device: Controlling Remote Device . . . . . . . . . . . . . 27
B.1 Hardware Circuit Diagram . . . . . . . . . . . . . . . . . . . . . . 28
C.1 CSS-ESS Protocol Overview . . . . . . . . . . . . . . . . . . . . . 33
v

List of Tables
5.1 Division of project work among team members . . . . . . . . . . 11
5.2 ESS Software Model Element Statistics Summary . . . . . . . . . 12
5.3 ESS Timeline Summary . . . . . . . . . . . . . . . . . . . . . . . 12
5.4 WebService Timeline Summary . . . . . . . . . . . . . . . . . . . 14
D.1 Device Con_guration File Format . . . . . . . . . . . . . . . . . . 35
vi

Chapter 1
Introduction
Computers and the related technologies are becoming more and more ubiquitous.
Various technical arenas in the _eld of Computer Science and Engineering,
or Information Technology have come very near to the common people. The
number of homes with Personal Computers1 is gradually increasing. A day will
come, somewhere in the long future, when PC is referred to in the same class
of \Food, clothing and shelter". Improvements in the Networking technologies
have fostered growth of very dense networks. Land line telephones have been
becoming less and less popular and people now prefer communicating while on
the move. ISPs are now laying down their own networks to provide broadband
Internet access to customers.
When people have a good connectivity at their disposal, with tremendous
power of mobile computing to supplement the same, we can think of \connecting
their home appliances to the mobile phone". With this, people would be able
to turn on and o_, and to some extent, control the appliances at their home
even from a distant place. One of the very basic examples of an utility of this
is { switching on the air conditioner in the room just some time before reaching
home, so that the room is su_ciently cool by then.
1.1 What the problem is
The usefulness of a long range remote control to home appliances has no limits.
A trivial setup facilitating such a thing would be to connect the home appliances,
via a circuit, to a computer, then install a server software on the PC to export
the device functionality on the internet, and then access the device from a smart
device. However, this has certain disadvantages.
1. PC are not server systems. They should typically not run \server" softwares.
2. It is necessary that every PC has a global IP address that is recognized
on the Internet. With the current stubborn setup of IPv4 and IPv6 not
picking up momentum, this would be a major challenge. Users would
de_nitely not be ready to shell out a lot of money for a leased IP address.
1Personal computers are referred to as PCs hereafter
1
V Sem Mini Project Report, Revision 1, December 3, 2004 2
Even if they are willing to, there is a very low limit to how many users
can get such a privilege.
3. Keeping so many client server systems secure is a serious problem. With
such unmanageable setup, maintaining the software system would be a
mammoth task.
The problem then is, to install a system that would facilitate many clients
to use its architecture and get their devices \online" very quickly, inexpensively,
and with minimal e_ort.
1.2 Importance of the problem
A commercial implementation of the idea in this project could speed up the
Home Automation activities. Remote access has always proved to add to the
utility of any existing setup. Toys, Televisions, Music Players, all have started
having a remote control, why not switches?
Users would desire this remote control as a service. They would at a maximum,
be ready to pay some \service charges" but would not be willing to invest
a lot of money on the pillars of a system that supports this remote access. A
system that allows many such \clients" to connect and use the \online appliance"
service is de_nitely desirable. More over, if the system supports many
classes of devices rather than just appliances, then the system would get more
versatile and can be widely used.

Chapter 2
State of the Art
A Remote Control is perhaps the most popular gadget today. Right from the
intense creativity of remotely controlling laser chip markers to the highly destructive
remotely ignitable bombs, from the pins to the planes, remote control
is not only occupying a omnipresence state, but is also enhancing its scope and
domains.
We have had InfraRed Remote Controls, which work over very short distances,
and RadioWave Remote Controls, which work over larger distances.
However, something fundamentally common with all these controls is that the
transmitter and receiver should both use some kind of wireless waves. Thus,
the range of the control is limited.
If some control is desired to be remote across the globe, the technology
required intensively uses satellites, and thus, such a control has not been able
to become so popular. The INTERNET is more than just a world wide web.
Mobile phones are the gadgets of this generation. Remote control based on
Internet on mobile phones seems to be satisfactory quench of the desire.
There have been attempts to write such implementations earlier. However,
most of them were targetted towards speci_c devices. The need is to write
generic device control applications.
3

Chapter 3
System Architecture
The happyRC.NET system consists of three main parts, namely the End User
Server System(ESS), the Central Server System(CSS), and the Smart Device
Client. Figure 3.1 shows the logical structure of these parts, and an outline of
the components therein.
Figure 3.1: Architecture of the overall System
A brief description of these components is as follows:
3.1 ESS
The End user Server System is a client1 application that runs on the user's PC.
It takes authentication details from the user and uses an encrypted TCP/IP
1The word Server System is a misnomer. The Client installed on ESS acts as if there was
a server exporting the device functionality
4
V Sem Mini Project Report, Revision 1, December 3, 2004 5
channel(See Appendix C) to talk to the CSS. It has a con_guration _le that
contains details about the controllable hardware attached to the PC. It is the
job of the ESS to understand commands from the CSS and change the device
state accordingly.
3.2 CSS
The Central Server System is the heart of the art. It has three roles to play, and
therefore has three components that export various important functionalities.
General Component The General CSS Component is where most of the functionality
resides. It is the job of this component to receive connections
from various ESS PCs, and maintain their authentication states. This
maintains a lookup information about exactly which ESS particular users
are connected from, and what the device con_guration of their system
is. It shares its memory space with the Remoting component described
next. It is the job of this component to proxy requests from the remoting
component to the ESS system, and return the occurrence of a success or
failure.
Remoting Component This component is a stub for .NET Remoting2 calls.
It gives a reference to an object which has proxy functions written to
allow Remoting clients to call functions of the General Component. Every
connection to this component instantiates a new object which maintains
the state (authentication, etc.) of the client. Methods in this object wait
for a reply from the General Component and send the reply back to the
client.
Web Service To facilitate easy HTTP3 access from smart clients, this component
becomes crucial. It sits on a web server (running IIS) and communicates
to the General Component via the Remoting Component. The
job of this component is to maintain authentication states over the web.
It should ask the Remoting Component to provide the description of the
user's device. It should then parse the description out, and display an
interface that can change the device state.
Put together, these components build up the CSS System which can provide
facilities for any user to register his device online, and later on, use browser
complaint smart client to remotely control the same.
3.3 Smart Device Client
This client is the tool that would act as a Remote Control to the users. This
interacts with the CSS and commands the ESS to change the state of their
device at a remote location. Figure 3.1 shows two kinds of these clients. They
are classi_ed on the basis of how thin clients they are.
2.NET Remoting is similar to SunRPC or JAVA RMI
3HTTP could be over TCP/IP or WAP
V Sem Mini Project Report, Revision 1, December 3, 2004 6
Smart Devices Running Browsers This category includes devices that are
very thin in functionality. Typically, these include mobile phones, Wireless
PDAs, etc. They do not have the capability of running large programs,
and ship with an operating system that provides a minimal browsing functionality.
All that these can do is display primary interfaces, and request
simple form submitted by the users. They need to interact with the Web
Service component of the CSS in order to facilitate service.
Smart Devices Running CSS Client Some devices have more features than
plain smart devices, and are smarter then we think. Pocket PCs that run
operating systems like Microsoft Windows CE have capabilities of running
custom programs. A custom made CSS client(See Appendix E) can be installed
on these devices so as to customize user interfaces. These devices
can skip the Web Service component and directly interact with the CSS
using .NET Remoting. Clearly, Laptops and Computers are smarter then
even pocket PCs, and they can fall into this category.
3.4 Architecture Notes
The happyRC.NET system uses a Client-Server architectural model. With a
second look, we _nd that it comprises of a single server that serves multiple
clients of two types viz., ESS and smart devices. It should be noted that ESS
and smart devices have a one to one relationship and they share the user's
identity in common. Although one ESS can be controlled using many di_erent
types of smart clients, two of these clients can not talk simultaneously with the
same ESS, for reasons of atomicity and consistency of operations.
The ESS is connected to the user's device using a parallel (LPT1) port. This
was preferred over a serial port so that we can work with 8 bits simultaneously
rather than memorise bits received from the serial port and work once all of
them are received. This de_nitely speeds up the operations.
The communication between CSS and ESS works on a Request-Reply protocol
that is encrypted with symmetric cryptography to avoid malicious attempts
of hack, man in the middle, or eavesdrop replay attacks. (See Appendix C.
The General Component and Remoting Component of the CSS share the
same memory as they run in a single instance of the same application process.
Communication between these is by simple means of object references.
The Web Service Component, as mentioned earlier, uses .NET Remoting
to access the functionalities of the General Component. Its communication
with the Smart Device is over a simple HTTP channel. Use of HTTPS like
SSL Protocols was avoided because they are not supported by all thin clients.
Transfers of crucial data like passwords on this link is encrypted using simple
(yet strong) algorithms.

Chapter 4
How happyRC.NET works
As with almost any other computer based system, the working of happyRC.NET
begins with the process of Installation followed by the successive use. Installation
of the ESS on the user's PC includes con_guration of the device.(See
Appendix A The brief working strategy of the system is outlined below.
4.1 Registering New User
After proper installation of the ESS client on the user's PC, the users need to
get authentication account on the CSS. Once the request for a new identity
on the CSS is granted by the administrator, an entry of the username and its
corresponded password is appended in the authentication database1.
4.2 Activating Remote Device
When the users log in to the system using the ESS, the ESS connects to the
CSS and veri_es their identity. Having done that, the CSS requests the ESS to
send the device details. The CSS parses the con_guration _le into an serialized
object and sends it over to the CSS. The device is now ready to be remotely
controlled
4.3 Showing Device State Change Interface
The users on the smart clients need to be given an interface for changing the
device state. To facilitate this, the client request the CSS to send them the
device con_guration details. These details are parsed based on the type and
groups of inputs and the interface is displayed.
4.4 Calculating New State Numbers
The device states are classi_ed into groups. For every group, there is a union
policy, like AND, OR, XOR. Every state is represented by a byte, and when in
1The database could well be a at _le.
7
V Sem Mini Project Report, Revision 1, December 3, 2004 8
groups, these bytes can be combined into one. Thus, if the policy of a certain
group is OR, a bitwise OR would be performed among all the states in that group.
This newly generated number is the state of that group.
For every such group speci_ed in the con_guration _le, a new state number
is calculated. These state numbers are ordered by their group numbers, say
1,2,3, and stored for further processing.
Group Zero is a special group, where there is no union policy. Every state in
this group is sent as if it were in an independent group and the state numbers
of all states in this device are added to the end of the stored list.
4.5 Changing the State
For every state number generated by steps in section 4.4, a request is sent to the
CSS to write the same onto the device. The CSS in turn forwards the request
to the ESS which does the actual action of writing the command to the parallel
port. Based on whether the action returned success or failure, the users need
to be noti_ed.
4.6 Logging O_
When the users log o_ from the smart clients, no signi_cant state changes occur
in the CSS. The ESS still remains connected, and users can again use the smart
client for further communication with device.
However, when the uses log o_ from the ESS, the CSS discards all dynamic
entries for this connection, and if some smart client tries to communicate with
that discarded identity, they are returned error.
4.7 Overall Activity Flow
Along with the activities mentioned in the earlier sections, there are minute
details that need to be described in order to understand how exactly the system
proceeds with the work ow. Figure 4.1 shows an activity ow diagram of the
system.
Here is an enumerated description of the activities. The enumeration shows
the primary activity ow. The ow might change a little in certain extended
use cases.
1. The user interface of the ESS system would be used by the user to enter
his authentication credentials.
2. The ESS program would set up a communication channel with the CSS,
thereby connecting and verifying the user's details.
3. If the authentication succeeds, the user is noti_ed that his device is ready
to be controlled remotely.
4. The ESS program parses the device's con_guration _le, and converts it
into objects describing the functionality of the device.
V Sem Mini Project Report, Revision 1, December 3, 2004 9
Figure 4.1: Overall Activity Flow Diagram
5. ESS communicates the details of the device to the CSS on the already
established channel, and sets up callbacks on the CSS, so that it can
receive interesting information from the same.
6. The CSS, when it receives the device details, it sets up a set of functions
for the device, on the web service, to be remotely invoked.
7. The CSS maintains a table containing entries of which authenticated user
is using which instance of the CSS-ESS messenger program.
8. A user can switch on his smart client. The client knows the CSS, or else,
asks the user about the address of the CSS.
9. If the client is able to establish a connection to the CSS, it asks authentication
details to the user.
10. The client calls the initialize function on the CSS by parameterizing it
with the authentication details.
11. The CSS veri_es the authentication and if the client is a_rmatively identi
_ed, it sends the device description to the client, along with the current
state of the device, if asked.
12. The client extracts a form out of the obtained description and displays it
to the user.
13. If the user suggests any changes in the form, the client parses those
changes, and categorizes them into batch requests to the server, depending
on the action groups.
V Sem Mini Project Report, Revision 1, December 3, 2004 10
14. For each request that the client makes to the CSS, the CSS sends a word
to the ESS that has to be written on the parallel port of the same.
15. The ESS acknowledges the CSS which in turn nods to the client.
16. The client maintains state using some form of cookies and repeatedly keeps
asking user for further change in the circuit. The user can choose to logout
or change his password.
17. Once logged out, there are no changes on the CSS and the ESS.
18. However, the user can choose to disconnect his circuit by closing the ESS
application. In such a case, the CSS would dump all the connection details,
including the device details of the disconnected ESS, into garbage.
19. In any use case, the client shall not allow remote disconnection of the ESS
application.

Chapter 5
Design Issues
In this chapter, we would give details about how the project was conceived and
built, i.e. the Analysis and design phase. Because the project team consists of
four members, the work was distributed in blocks of modules as described in
Table 5.1.
Table 5.1: Division of project work among team members
Modules Primary Assignment Person
Hardware Circuit Varun Khullar
ESS Client, Security Parlikar Alok Ulhas
CSS (General Component) Shubham Shrestha Agrwal
CSS (Web Service), Architecture Nishant Shrivastava
Because the modules have been designed almost independently, the design
issues are separately sectioned.
5.1 ESS Client Design
The ESS client task was subdivided into the following activities.
Interacting with the Hardware This task involved writing a byte into the
parallel port. The Managed Runtime of the .NET platform that was being
used to develop the project does not allow \unsafe" I/O calls like this, and
hence a DLLImport followed by a call to one of the entry points in the
DLL was to be performed. The Windows documentation mentions how
the Kernel API can be used to interact with external devices.[Mic03]
The other essential thing was to tell the software, details of the hardware
connected. To do this, a con_guration _le format was formulated. The
format allows access to devices with up to 256 states. More details of the
format can be found in Appendix D.
Communicating with the CSS This task involved formulating a protocol
that works over TCP/IP channel, and then an implementation of the same.
The protocol was formulated taking a skeleton of SMTP like Request-
Reply protocols. Details of the protocol and how the transmission is suf-
_ciently strongly encrypted can be found in Appendix C.
11
V Sem Mini Project Report, Revision 1, December 3, 2004 12
The User Interface This task involved creating a GUI for the user to interact
with the system. Some salient features of the GUI are:
1. Strict validation of inputs
2. Based on a state machine
3. User friendly errors
4. Use of registry to save settings. The key used for the purpose is
HKEYnLocalMachinenSoftwarenhappyRC
The ESS was designed in a round trip engineering mode. To start o_, we
had a basic class diagram, with bare functionality built in. Then an automated
code generation was done. That code was edited, and the diagrams modi_ed
accordingly.
The class diagram was always synchronized, and many times, adding
more functionality was done from within the diagram. The tools Microsoft Visual
Studio .NET 2005 and Microsoft Visio Enterprise Architect 2005 were very
handy in this kind of approach.
Table 5.2 shows the Element Statistics Summary of the ESS Software. It
should be noted that the numbers in the table also count the classes and packages
that the .NET provides. For example, every object is a specialization of the
Object class, and hence the counter for Generalizations is that high.
Table 5.2: ESS Software Model Element Statistics Summary
Number of Interfaces 17
Number of Classes 41
Number of Data Types 2
Number of Attributes 81
Number of Parameters 62
Number of Operations 53
Number of Generalizations 45
Number of Packages 11
Number of Subsystems 1
Table 5.3 shows the Timeline Details imported as text from the Grant Chart.
Dates speci_ed herein are not Assigned Dates, but are Actual dates. (That is,
these are a posteriori Grant Chart Details).
Table 5.3: ESS Timeline Summary
Task Name Start Date Duration(Days) End Date
Analysis of Software Tue 3/8/04 8 Thu 12/8/04
Basic Use Cases Wed 11/8/04 7 Thu 19/8/04
Basic Class Diagram Sun 22/8/04 8 Wed 1/9/04
Coding Implementation Wed 1/9/04 25 Tue 5/10/04
Minute Design Changes Fri 24/9/04 3 Tue 28/9/04
Testing/Debugging Tue 28/9/04 25 Mon 1/11/04
Deployment Ready Wed 17/11/04 3 Fri 19/11/04
The \Design Changes" mentioned in this Table (5.3) involved splitting up a
class into two. The Refactoring tools in Visual Studio were used for the purpose.
V Sem Mini Project Report, Revision 1, December 3, 2004 13
5.2 CSS Server Design
The CSS Server has following functions to perform:
Interacting With the ESS The implementation of the protocol formulated
with the ESS was an obvious task. However, certain issues which differed
from the ESS was the presence of multiple ESS clients. To take
care of many clients, the CSS had to be implemented as a state machine
based program. Asynchronous read functions were made for robust state
machine.
Communicating via .NET Remoting .NET remoting was used to export
the functionality of the General CSS component to the smart client world.
TCP channel is used for the communication. The exported functionality
is documented in Appendix E.
The user Interface The task involved creating the GUI for the user to interact
with the system. The GUI is also implemented as a state based
machine.
The CSS was designed using the prototyping principle. A basic prototype was
_rst built, and more functionality was added in increments.
5.3 WebService Design
Thought behind the Design
The basic aim of this project is to provide a method to general users who don't
want to go into the technical details and yet reap the bene_ts of technological
advances to their bene_ts.This basic aim couldnot have been ful_lled if it
required some expensive WindowsCE enabled mobile phone which costs something
in excess of 40,000 rupees to remotely controll the user's home appliances.
Therefore the method to be implemented on the mobile devices had to be something
on the lines of a web service which could be access from any Internet
enabled mobile phone.
Choice of Technology to use
Initially, we felt we would encounter some grave problems in correctly identifying
the Mobile Device device making the request , whether it is a PDA, WAP
enabled mobile phone or the ultimate smart device a computer and reply to
the request in the suitable format .i.e WML if the requesting agent is a WAP
enabled Mobile phone, HTTP if the request comes from a Laptop or a Computer
or in a format compatible with PDAs. But after some reading in this direction
we discovered that we need not worry that much because ASP .Net provided
mobile controls and all we needed was to make a .Net Mobile page and the IIS
server would do the task of identifying the requesting agent and generate the
output in the suitable format. Connection to a web server was practical solution
also because it allows users to connect from any place which has Internet Access
and also to do away with the need of the end systems to have a static IP address.
V Sem Mini Project Report, Revision 1, December 3, 2004 14
Interaction with the CSS
The basic interface was made in ASP.Net using Mobile controls with C# as the
script powering the ASP.Net page.The interaction with the CSS was using .Net
Remoting by creating a Client Activated Object over a TCP channel with the
CSS.[Gri02]
Backend Implementation Summary
A .Net Remoting Client Activated TCP channel is created with the CSS as
soon as the user provides his login ID and password. If the username and the
password match with those in the Database at the CSS, the user is successfully
authenticated. The CSS on request transmits to the Web Server data about the
state of the User's ESS and the groups and the policy associated with groups
of the User's appliances. After receiving the request of the user, as to what
changes he wishes to make to the _nal state of the appliances, the _nal state
of the end System is calculated and the words to output to the end system are
transmitted to the CSS which in turn sends the data to the ESS.
Table 5.4: WebService Timeline Summary
Task Name Start Date Duration(Days) End Date
Analysis of Software 6/8/04 8 15/8/04
Basic Use Cases 16/8/04 2 Thu 17/8/04
Coding Implementation Wed 12/9/04 13 Tue 26/9/04
Minute Design Changes Fri 24/10/04 3 Tue 28/10/04
Testing/Debugging Tue 28/10/04 4 Mon 1/11/04
Deployment Ready Wed 1/11/04 2 Fri 4/11/04

Chapter 6
Speci_c Technologies used
6.1 .NET Framework
The .NET Framework is a new computing platform that simpli_es application
development in the highly distributed environment of the Internet.[Mic03] The
.NET Framework is designed to ful_ll the following objectives:
_ To provide a consistent object oriented programming environment whether
object code is stored and executed locally, executed locally but Internetdistributed,
or executed remotely.
_ To provide a code-execution environment that minimizes software deployment
and versioning conicts.
_ To provide a code-execution environment that guarantees safe execution
of code, including code created by an unknown or semi-trusted third party.
_ To provide a code-execution environment that eliminates the performance
problems of scripted or interpreted environments.
_ To make the developer experience consistent across widely varying types
of applications, such as Windows-based applications and Web-based applications.
_ To build all communication on industry standards to ensure that code
based on the .NET Framework can integrate with any other code.
The .NET Framework has two main components: the common language
runtime and the .NET Framework class library. The common language runtime
is the foundation of the .NET Framework. One can think of the runtime as
an agent that manages code at execution time, providing core services such as
memory management, thread management, and remoting, while also enforcing
strict type safety and other forms of code accuracy that ensure security and
robustness. In fact, the concept of code management is a fundamental principle
of the runtime. Code that targets the runtime is known as managed code, while
code that does not target the runtime is known as unmanaged code. The class
library, the other main component of the .NET Framework, is a comprehensive,
object-oriented collection of reusable types that you can use to develop
15
V Sem Mini Project Report, Revision 1, December 3, 2004 16
applications ranging from traditional command-line or graphical user interface
(GUI) applications to applications based on the latest innovations provided by
ASP.NET, such as Web Forms and XML Web services.
The .NET Framework can be hosted by unmanaged components that load
the common language runtime into their processes and initiate the execution of
managed code, thereby creating a software environment that can exploit both
managed and unmanaged features. The .NET Framework not only provides
several runtime hosts, but also supports the development of third-party runtime
hosts.
6.1.1 The Common Language Runtime
Compilers and tools expose the runtime's functionality and enable you to write
code that bene_ts from this managed execution environment. Code that you
develop with a language compiler that targets the runtime is called managed
code; it bene_ts from features such as cross-language integration, cross-language
exception handling, enhanced security, versioning and deployment support, a
simpli_ed model for component interaction, and debugging and pro_ling services.
To enable the runtime to provide services to managed code, language compilers
must emit metadata that describes the types, members, and references
in your code. Metadata is stored with the code; every loadable common language
runtime portable executable (PE) _le contains metadata. The runtime
uses metadata to locate and load classes, lay out instances in memory, resolve
method invocations, generate native code, enforce security, and set run-time
context boundaries.
The runtime automatically handles object layout and manages references to
objects, releasing them when they are no longer being used. Objects whose
lifetimes are managed in this way are called managed data. Garbage collection
eliminates memory leaks as well as some other common programming errors. If
your code is managed, you can use managed data, unmanaged data, or both
managed and unmanaged data in your .NET Framework application. Because
language compilers supply their own types, such as primitive types, you might
not always know (or need to know) whether your data is being managed.
The common language runtime makes it easy to design components and applications
whose objects interact across languages. Objects written in di_erent
languages can communicate with each other, and their behaviors can be tightly
integrated. For example, you can de_ne a class and then use a di_erent language
to derive a class from your original class or call a method on the original class.
You can also pass an instance of a class to a method of a class written in a
di_erent language. This cross-language integration is possible because language
compilers and tools that target the runtime use a common type system de_ned
by the runtime, and they follow the runtime's rules for de_ning new types, as
well as for creating, using, persisting, and binding to types.
6.2 .NET Remoting
.NET remoting enables the programmer to build widely distributed applications
easily, whether application components are all on one computer or spread out
V Sem Mini Project Report, Revision 1, December 3, 2004 17
across the entire world. One can build client applications that use objects in
other processes on the same computer or on any other computer that is reachable
over its network. One can also use .NET remoting to communicate with other
application domains in the same process.
.NET remoting provides an abstract approach to interprocess communication
that separates the remotable object from a speci_c client or server application
domain and from a speci_c mechanism of communication.[Mic03] As a
result, it is exible and easily customizable. One can replace one communication
protocol with another, or one serialization format with another without recompiling
the client or the server. In addition, the remoting system assumes no
particular application model. One can communicate from a Web application, a
console application, a Windows Service from almost anything one wants to use.
Remoting servers can also be any type of application domain. Any application
can host remoting objects and provide its services to any client on its computer
or network.

Chapter 7
Conclusion and Future
Scope
In this report, we described happyRC.NET as a project that helps us talk to
devices that are connected to a remote computer. A careful implementation of
the idea suggested by the project can prove to be very bene_cial in promoting
home automation and similar activities. This project can be considered as a
proof of concept { the concept that it is possible to mobilize the control of
appliances.
What this project does in the ESS, i.e. interaction with the hardware, could
as well be performed on an embedded system. Agreed, IPv6 is taking time to
gain dominance, but assuming that in such a world, there is no dearth of IP
addresses, almost every device could have an IP address, and an Embedded ESS
of its own, to make life of people even more easier. What is a Remote Control
today, would get replaced by a Mobile Control.
This project lacks support for devices that have more than 256 states. More
over, this can control only state based devices. There are some devices that are
activity based, not state based. For most needs, changes in the con_guration
_le format would su_ce for getting a proper support for the required device.
For example, these changes could be { adding new action types, or more group
policies, etc. However, in rare cases, the application might have to be slightly
restructured.
18

Appendix A
User Manuals
The user manual of the ESS, CSS, and the Interface.
A.1 Manual for the ESS Client
The ESS Client is a light weight application taking about 96KB on the disk.
This section deals with the installation and usage details of that application.
A.1.1 Requirements
Although e_orts were made to keep the ESS Client as light as possible, it still
has a set of minimum system requirements, as follows:
_ Microsoft Windows1 98 and Later.
_ .NET Framework version 2.0 or later
_ Network Connection
_ Parallel Port (LPT1) on the host system
A.1.2 Installing the Application
Instead of using the default InstallShield types of installation, the ESS client
has been deployed as a Click Once application. The deployment folder would
contain a \Setup" utility which can be used to directly run the application.
Below are given the basic installation steps.
1. Locate the Installation Folder. If the folder resides on a network share,
copy it to your local disk.
2. Run the _le Setup.exe.
3. If you get a screen as shown in Figure A.1, please read the license carefully
and click the Accept button to proceed. This error had come because you
had not installed the .NET Framework 2.0, and hence, it required to be
1Itis possible to port the client to other operating systems like Linux, however the application
as a part of this project compiles, but does not run on Linux
19
V Sem Mini Project Report, Revision 1, December 3, 2004 20
installed. Once you are done with the installation, restart your system
and continue with the installation of this application.
Figure A.1: Installation of .NET Framework 2.0
4. The installation would check for system requirements, during which it
would show a progress splash screen as shown in Figure A.2.
Figure A.2: ESS Client Installation Requirements Veri_cation
5. If you get a dialogue as shown in Figure A.3, you must be running the
setup from a network location. Make sure you have copied the installation
_les to your local system.
6. If your system had met the requirements of the application, it would get
successfully installed. A shortcut would be added to the Start Menu, at
the location All Programs -> IIITA. You can use this shortcut to run
the application.
7. Just after the installation, the application would start running. You may
proceed to start using the same.
V Sem Mini Project Report, Revision 1, December 3, 2004 21
Figure A.3: ESS Client Installation Security Warning
A.1.3 Using the Program
Running the Application
_ The application installation creates a desktop shortcut for the application.
You can run the application from the desktop.
_ You can also run the application from the start menu. The shortcut
would be installed at the location: Start -> All Programs -> IIITA
-> happyRC Client.
When the application runs, you would get a screen as shown in Figure A.4.
Figure A.4: ESS Application Login Screen
V Sem Mini Project Report, Revision 1, December 3, 2004 22
Changing the Settings
Before using the program, you must know the location of the CSS server and
the location of the con_guration _le for your device. To change the existing
settings,
1. From the Login screen, (Figure A.4) click the \Change Settings" link. You
would be presented with a form that looks as in Figure A.5.
Figure A.5: ESS Application Settings Dialogue
2. Enter the CSS server's IP address or host name in the _rst _eld.
3. Enter the CSS server's port number (default: 8221) in the second _eld.
4. In the third _eld, select the location of the device con_guration _le on
your system.
5. Once you click the Update button, the application would try to verify the
settings. If any of the settings is incorrect, a red blinking icon would be
placed next to that _eld. Hover the mouse over that box to see what error
was encountered, and take appropriate corrective steps.
6. If the updation is successful, the application would return back to the
login screen.
Logging in
1. At the login screen (Figure A.4), enter your authentication credentials.
2. Please note that the username has to be alphanumeric word, and that the
password can not be blank.
V Sem Mini Project Report, Revision 1, December 3, 2004 23
3. On clicking the Login button, the application would try to log you onto
the CSS server. If the authentication fails, you would get a noti_cation of
the same.
4. If the authentication times out, you would be noti_ed about the same too.
You may then try authenticating again.
5. If the authentication is successful, the application displays the \Logged
In" dialogue as shown in Figure A.6.
Figure A.6: ESS Application { User Logged In
Changing the Password
1. Follow steps in Section A.1.3 to log on from the ESS client. This would
take you to the Logged In screen(Figure A.6).
2. Click the Change Password link. You would be taken to the password
change interface as shown in Figure A.7.
3. Enter the old and new passwords. Also enter the new password again, for
con_rmation, and click the Change button. If the password change was
successful, you would be taken back to the Logged In Screen (Figure A.6).
4. In case there is some error changing the password, a red blinking icon
would be displayed on the screen which would show the exact error on
hovering the mouse over it. Please read the error and take the suggested
corrective action.
V Sem Mini Project Report, Revision 1, December 3, 2004 24
Figure A.7: ESS Application { Change Password
Logging Out
From the Logged In Screen (Figure A.6), click the Logout link in order to log out.
The application will ask for a con_rmation during logout. Click OK to continue
with the logout. You would be presented with the Login screen (Figure A.4)
again.
A.2 Manual for the CSS Server
The CSS is a server application that runs on a system on the Internet and allows
many end users to connect to the their devices attached through the ESS. This
section deals with the usage details of the server.
A.2.1 Requirements
The CSS provides many to many connectivity for its users, and thus it is required
that the underlying OS of the system supports this heavy network load. Here
is a set of minimum requirements.
_ .Net Framework 1.1 or Higher
_ Windows Server 2003 (Recommended) or Windows XP (Professional)
A.2.2 Using the Program
The Interface of software on startup shows Login screen (Figure A.8) where
Administrator can Log on. After logging in the user has option of starting
V Sem Mini Project Report, Revision 1, December 3, 2004 25
the server and perform any of the admin tasks for which GUI interface. The
administrator can also start the server which will start the server on request of
client will connect to ESS Client.
Figure A.8: CSS Login Screen
Logging in
1. Start the application.
2. Enter userId and password in the login screen.
3. If your credentials are authentic, and you have administrator rights assigned,
the system would log you in.
Logging out
The application would log the administrator out at the click of the Logout
button.
Starting the Server
1. Start the application.
2. Log in with admin rights
3. Click on start server button after logging in.
Note: The server will keep running until you don't close the application or
you do not stop the server. Logging out would not stop the server.
Stopping the Server
If the server is running, and you are logged in, you can click the Stop Server
button to stop the server.
V Sem Mini Project Report, Revision 1, December 3, 2004 26
User Management
1. Log in as told above.
2. Click the Admin task button after logging in.
3. Select the appropriate activity, from those shown in Figure A.9.
4. Write the user's name for performing that activity and click OK.
Figure A.9: Administration Tasks on the CSS
A.3 Manual for the CSS Webservice
The user interface of the webservice provides strict validation of inputs and
generates proper messages reecting the state of the connection. The user is
asked to authenticate at the _rst page where he sees a Login Screen prompting
for a Username and a Password to initiate the communication. (See Figure
A.10)
Figure A.10: Smart Device: Logging in
V Sem Mini Project Report, Revision 1, December 3, 2004 27
If Authentication fails, he is asked to re-enter his username and password.
On Authentication with a valid Username and Password, he can choose either
to change his password or to Control the devices thus ful_lling his dream of
Home Automation. See Figure A.11
Figure A.11: Smart Device: Authentication Process
On successful change of password, user is asked to relogin with the new
password. If he selects to Control his devices screen generates the list of the
appliances connected to his end system and by means of checkboxes and Text
input, he inputs the _nal state of the end system device. On selecting the
selection Option, the device List is shown on the Mobile Screen. User makes his
selection and sends the request back to the server. (See Figure A.12)
Figure A.12: Smart Device: Controlling Remote Device
Any time during the process, the user can select the Logout link to securely
log out from the control interface.

Appendix B
Hardware Details
The following components were used to build the hardware.
_ Relays- OMROM 5A/25 V DC : 10A/220 V Ac : 12V DC
_ Optocouplers- 4N35 1.2v to drive.
_ Resistors- 1 kilo ohm.
_ DC Adaptor or Transformer -12V.
_ Switch and socket, Bulb
The relay is used as a electromechanical relay. The circuit consists of four
independent sub-circuits which in turn can run four di_erent aplliances. The
parallel port gives a potential of 3.3v to 3.5v which has been used to drive the
optocoupler. The optocoupler is used as a switch for a 12v DC supply (given
by a transformer). This 12V is being used to Switch on the relay. The relay is
connected to 220 volts AC power supply. This power supply is now controlled
by parallel port and can be used to run various appliances.
Figure B.1 shows the circuit diagram of the connection.
Figure B.1: Hardware Circuit Diagram
28

Appendix C
CSS-ESS Protocol Details
This Appendix mentions details about the protocol that the CSS and ESS use
to talk to each other. A one liner description of the protocol is "Request Reply
protocol over Encrypted TCP/IP Channel". The following sections explain how
di_erent issues are tackled in the protocol.
C.1 Getting Connected
The CSS has a General Component that listens to a speci_c TCP port on
the server machine. The ESS Client must know this port number in order to
establish a connection. Having known the same, it establishes a regular TCP
connection using Network Sockets.
C.2 Security Paranoia and Encryption
C.2.1 Two Types of Cryptography
There are two basic kinds of cryptography[Tan00]. In Symmetric Cryptography,
the two entities that wish to communicate use the same key. Algorithms like
DES are used to encrypt and decrypt a given text, and this shared key is required
for the purpose. In Asymmetric Cryptography, every entity has a pair of keys
containing, one public key and other private key. Algorithms like RSA are used
to encrypt the text. To send encrypted data to someone, his public key is used
in the encryption algorithm. This text can not be decrypted by any other key
than the corresponding private key.
The performance of symmetric key cryptography is better as compared to
asymmetric key cryptography. However, the concept of \shared key" presents
a problem. Sharing the key becomes a crucial issue. One has to create this key
and send it to the other. If some person taps their connection, the beauty of
this algorithm gets pretty useless. Sharing keys1 is quite better with public key
cryptography, one just needs to send the public key. However, there still present
problems of security attacks.
1Generally, the encryption algorithms used are symmetric, but the key transfer is done by
encrypting the symmetric key in a public key encryption.[Sta02]
29
V Sem Mini Project Report, Revision 1, December 3, 2004 30
C.2.2 Security Attacks
Trivial Network Tapping
This kind of an attack can occur if the symmetric key is transferred over an
insecure channel. Once an evesdropper gets hold of the key, all algorithms
become very useless.
Log and Replay
Algorithms that have their keys hard coded are vulnerable to this attack. Because
the key for their encryption and decryption are same at all times, an
evesdropper can record a transaction between two parties by tapping the network
line. He might not be able to understand their conversation, may be,
because he might not have the keys. However, he can send back the same data
and pretend to be the authorized user who was sending that data earlier. The
other party can not distinguish between the initial transaction and the replay
attack.
Man in the Middle
The biggest problem even with public key cryptography is this attack. Instead of
just tapping the network line between two parties, the evesdropper this time sits
in between them. Right from when the key transfer takes place, this evesdropper
proxies the connection between the parties, and also proxies for the public keys.
He can thus not only understand the conversation between the parties, but also
change the same without the understanding of any of the parties.
C.2.3 Security Solution in happyRC.NET
The above mentioned attacks were carefully avoided in the security implementation
of this system. A synopsis of the encryption algorithms is explained
followed by the details of how the above attacks are avoided.
The Solution Details
_ The system employs symmetric (shared key) cryptography
_ The Rijndeal algorithm is used for the encryption.2
_ The shared key is not _xed, but is generated dynamically.
_ The key is generated from two salts { a random string, and the user's
password.
Defense against Attacks
It is important to note the following.
_ The user's password is known to the ESS as the user is going to enter it
for authentication purposes.
2.NET provides a class for the same.
V Sem Mini Project Report, Revision 1, December 3, 2004 31
_ The user's password is known to the CSS because it has a password
database.
_ No one else knows the user's password. (The user is supposed to keep it
secret)
A Symmetric Cryptography algorithm begins with sharing of the key. The
key that we are using is generated from two parts, one of which is known to
both the ESS and CSS. After the connection, CSS generates a random string
and transmits it plain text to the ESS. Using this string and the password, both
of them generate a \shared" key.
1. Because any evesdropper does not know the user's password, even if he
reads the random string, he can not generate the key that is shared by
CSS and ESS.
2. Because the generated key depends on a random string, which ought to
be di_erent for every connection, the \shared key" is di_erent for every
connection, and thus, the evesdropper can not replay his transaction log
onto the network.
Thus we see that the attacks of tapping, Log-Replay and man in the middle are
defended by the system.
C.3 The Request Reply Protocol
The following text describes the messages that are passed between the CSS and
ESS. Please note that the text written in Typewriter Style is an encrypted
message, and any message that is transferred plain text is written in Slanted
Text. Also note that every message ends in a Line Feed Character(\n).
C.3.1 Key Transfer
After connection, the ESS initiates the dialogue. The _rst messages between
the systems is as follows:
ESS: KEY userName
CSS: KEY 50meR4nd0m5+r1ng
When CSS receives the username, in the _rst message, it _rst calculates a
random string and sends it back to ESS. It then retrieves the user's password
from the database and using this and the random string, generates the shared
key. When ESS gets the second message, it uses the user provided password
and this random string to compute the shared key. Thus, at the end of this
transaction, both share the same key.
Note: If the user enters an incorrect password in the ESS interface,
at the end of this process, the CSS and ESS would have di_erent keys.
This is handled during the authentication
C.3.2 Client Authentication
After the key transfer, the ESS proceeds with the authentication and the following
dialogue takes place:
V Sem Mini Project Report, Revision 1, December 3, 2004 32
ESS: AUTH userName pA55w0rd
CSS: OK
OR
ESS: AUTH userName pA55w0rd
CSS: ERR
The ESS sends an encrypted text containing the username and password
of the user. If the password was correct, the message could be decrypted by
the CSS. In such a case, it would reply with a plaintext OK saying that the
authentication is done. If it is not able to decrypt, it understands that the ESS
had a di_erent shared key because the user entered incorrect password, and
hence returns ERR in plain text.
Note: The CSS replies to the authentication request in plain text. This was
necessary because if the user has entered incorrect password, it would not be
able to decrypt even the ERR response, and there would be a in_nite loop in
the state machine.
C.3.3 Getting the Device Details
After successful authentication, the CSS requests the ESS to send it the description
of the device connected. The ESS has an object containing the description.
It is serialized and base64-encoded and returned as a reply as follows.
CSS: DESC
ESS: DESC base-64 encoded serialized object
The serialized object is typically XML, and contains many line breaks. In
the protocol, every message terminates with a linefeed, and thus, the serialized
text can not be passed as it is. Hence, the base 64 encoding is applied to the
same.
C.3.4 Commanding the ESS
When the CSS gets requests from the smart client, for changing the device state,
it has to tell the ESS to write some byte to the port. Following is the dialogue
that takes place.
ESS: WRITE byte
CSS: OK
OR
ESS: WRITE byte
CSS: ERR
Given the byte, the CSS attempts to write it to the port. In most cases, the
call succeeds, and CSS replies with OK. However, in some cases, the write to the
port fails. For example, if someone maliciously tried to write a number with
value more than 255 (maximum for a byte), then this call would fail, and ESS
would reply in an error.
C.3.5 Logging O_
The user on the ESS may choose to log his client o_. It is the job of the ESS
to notify the CSS about the action and then close the network connection.
ESS: OFF
V Sem Mini Project Report, Revision 1, December 3, 2004 33
The ESS closes the socket immediately after this transfer. The CSS should
close its end too, after it gets the noti_cation.
C.3.6 Exceptional Messages
It might happen that even after the proper authentication, etc. of the ESS with
the CSS, some error might creep in. This should not happen with the actual
clients, but some malicious hacker might attempt sending messages that are
out of context. To handle such situations, the CSS sends the following message
whenever it does not understand what the message was.
CSS: EMERGENCY
Note that an invalid operation usually results in just ERR. Only in certain
exceptional cases, like invalid description will this message be used. The CSS
would close the connection after sending this message. The ESS noti_es a fatal
error on getting this response from the CSS.
C.4 Protocol at a glance
The earlier section describes that the protocol uses the commands KEY, AUTH,
DESC, WRITE, OFF, EMERGENCY, OK, and ERR. Figure C.1 shows a
graphical overview of the protocol.
Figure C.1: CSS-ESS Protocol Overview

Appendix D
Device Con_guration File
Format
This Appendix discusses the format for the _le that speci_es details about the
hardware connected to the ESS. This Con_guration File can be located any
where on the system that has ESS installed. Path to the correct _le can be set
from the ESS program.
This Con_guration File is a tab separated text _le. There are two sections
in the _le.
The _rst section stores information about the various \Actions" that can be
performed on the devices. Every record in this section contains four _elds, as
follows:
Byte This is the byte word that has to be written on the parallel port so as to
perform that action.
Type This speci_es what kind of an input the Action should be provided with.
It could either be 0(for a toggle input) or 1(for numeric input). It is
assumed that with numeric inputs, the request would be repeated speci_ed
number of times to carry out the action.
Description This is a string _eld which would be displayed to the user. This
should be terse, nonetheless, very descriptive, because the user should be
able to identify this action completely.
Group Actions can be grouped together. All actions of the same group have
this _eld value the same. This _eld contains integer values 1,2,. . . ,n. There
might be some actions that can not be grouped. Group number 0 is used
for such actions.
The second section stores information about the various \Groups". We had
classi_ed actions into groups in the earlier section. There has to be a policy
so that the bytes for those actions can be combined. This section de_nes the
policy. Every policy is one character out of | & ^ which represent OR, AND and
XOR respectively. These policies are applied as bitwise operations. For example,
if actions A, B, C are in one group with the policy OR, then a byte would be
generated by performing bitwise or of the bytes of the actions A, B and C. The
34
V Sem Mini Project Report, Revision 1, December 3, 2004 35
_le should ideally not contain a newline at the end of _le, although that would
result in no fatal error.
These two sections need to have a delimiter that is a sentinel to the _le. For
this purpose, a line with just ### as the text is used. Table D.1 speci_es a
general structure of the _le.
Table D.1: Device Con_guration File Format
Byte1 Type1 Description1 Group1
Byte2 Type2 Description2 Group2
Byte3 Type3 Description3 Group3
...
...
...
...
###
Group1 Policy1
Group2 Policy2
Group3 Policy3
...
...
EOF

Appendix E
Developer Details { Writing
a client for CSS
The Client for the .Net Remoting Service depends on the type of server running
the Remoting Service.
In order to implement the .Net Remoting Client, we need to use the classes
System.Runtime.Remoting and System.Runtime.Remoting.Channels.
Because the architecture of the CSS supports many clients to one server, use
of Server activated objects is not possible. Client-activated objects are analogous
to common class instances where each caller gets its own copy of the object.
Every client of this system must keep his own copy of the object, and maintain
states (like authentication information) in the same.
The Remoting Component of the CSS exports the following functionality for
the clients:
Authenticate(username,password) Returns true if the user was properly
authenticated.
Get Con_g() Returns an object containing the con_guration of the device.
This object belongs to class Con_gData and details about the same can
be found in the code documentation.
Write Word(byte) Attempts to write the given byte as a state to the device
connected to the ESS. Returns success or failure as a boolean.
Change Password(old, new) Attempts to change the user's password and
returns a boolean that describes success or failure.
Get LastByte() Returns the byte that was last written to the ESS client.
Logo_() Sets the authentication state to false.
36

Bibliography
[Gri02] Fergal Grimes. Microsoft .NET for Programmers. Manning Publications
Co., 2002.
[Lam03] Leslie Lamport. LATEX - A document preparation system. Pearson
Education, 2 edition, 2003.
[Mic03] Microsoft. MSDN Documentation, 2003.
[Sta02] William Stallings. Cryptography and Network Security. Pearson Education
Asia, 2 edition, 2002.
[Tan00] Andrew S. Tanenbaum. Computer Networks. Prentice Hall of India,
2000.
37