Tele Byte

8/7/2019 Tele Byte

1/45

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.

8/7/2019 Tele Byte

2/45

Abstract

We propose to install a system that shall enable an electronic switching deviceinterfaced with a computer to be controlled remotely using a smart device. Aclient running on the users computer would connect to a central server, overan Internet connection. The user could then use a HTTP/WAP protocol froma smart device to connect to the central server, and issue requests to control hisdevice.

In this report we describe happyRC.NET the set of software and hardwaresetup that helps in addressing to the problem we have identified. We explain themethodology that this system has adopted to tackle the issue. We also explainthe security considerations that we have focused on while designing the customclient server protocols. In the end, we conclude with possible enhancementsin the project that might take us to a whole new world of remotely operated

gadgets in every home.

8/7/2019 Tele Byte

3/45

Acknowledgment

The authors gratefully acknowledge the guidance provided by the project su-pervisor Dr G. C. Nandi throughout the development of the project.

The authors also wish to thank the other faculty members for their valuablesuggestions and directions.

The authors also thank their batch mates for providing constant encourage-ment, support and valuable suggestions during the development of the project.

i

8/7/2019 Tele Byte

4/45

Candidates Declaration

We hereby declare that this project report titled happyRC.NET Remote Con-trolled Electronic Switching System submitted towards the completion of MiniProject in 5th semester of B.Tech(I.T.) in Indian Institute of Information Tech-nology, Allahabad is an authentic record of our work carried out under theguidance of Dr. G. C. Nandi, Dean(Academics), IIIT Allahabad.

Date: December 3, 2004Place: Allahabad

Parlikar Alok Ulhas Nishant Shrivastava

Shubham Shrestha Agrwal Varun Khullar

Certificate

This is to certify that the above declaration made by Mr. Nishant Shrivastava,Mr. Parlikar Alok Ulhas, Mr. Shubham Shrestha Agrwal and Mr. Varun Khullaris true to the best of my knowledge and belief.

Date: December 3, 2004Place: Allahabad

Dr. G. C. Nandi

Dean (Academics)Indian Institute of Information Technology, Allahabad

ii

8/7/2019 Tele Byte

5/45

Contents

1 Introduction 11.1 What the problem is . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2 Importance of the problem . . . . . . . . . . . . . . . . . . . . . 2

2 State of the Art 3

3 System Architecture 43.1 ESS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43.2 CSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53.3 Smart Device Client . . . . . . . . . . . . . . . . . . . . . . . . . 53.4 Architecture Notes . . . . . . . . . . . . . . . . . . . . . . . . . . 6

4 How happyRC.NET works 74.1 Registering New User . . . . . . . . . . . . . . . . . . . . . . . . 74.2 Activating Remote Device . . . . . . . . . . . . . . . . . . . . . . 7

4.3 Showing Device State Change Interface . . . . . . . . . . . . . . 74.4 Calculating New State Numbers . . . . . . . . . . . . . . . . . . 74.5 Changing the State . . . . . . . . . . . . . . . . . . . . . . . . . . 84.6 Logging Off . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84.7 Overall Activity Flow . . . . . . . . . . . . . . . . . . . . . . . . 8

5 Design Issues 115.1 ESS Client Design . . . . . . . . . . . . . . . . . . . . . . . . . . 115.2 CSS Server Design . . . . . . . . . . . . . . . . . . . . . . . . . . 135.3 WebService Design . . . . . . . . . . . . . . . . . . . . . . . . . . 13

6 Specific Technologies used 156.1 .NET Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

6.1.1 The Common Language Runtime . . . . . . . . . . . . . . 166.2 .NET Remoting . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

7 Conclusion and Future Scope 18

A User Manuals 19A.1 Manual for the ESS Client . . . . . . . . . . . . . . . . . . . . . . 19

A.1.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 19A.1.2 Installing the Application . . . . . . . . . . . . . . . . . . 19A.1.3 Using the Program . . . . . . . . . . . . . . . . . . . . . . 21

A.2 Manual for the CSS Server . . . . . . . . . . . . . . . . . . . . . 24

iii

8/7/2019 Tele Byte

6/45

A.2.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 24

A.2.2 Using the Program . . . . . . . . . . . . . . . . . . . . . . 24A.3 Manual for the CSS Webservice . . . . . . . . . . . . . . . . . . . 26

B Hardware Details 28

C CSS-ESS Protocol Details 29C.1 Getting Connected . . . . . . . . . . . . . . . . . . . . . . . . . . 29C.2 Security Paranoia and Encryption . . . . . . . . . . . . . . . . . 29

C.2.1 Two Types of Cryptography . . . . . . . . . . . . . . . . 29C.2.2 Security Attacks . . . . . . . . . . . . . . . . . . . . . . . 30C.2.3 Security Solution in happyRC.NET . . . . . . . . . . . . 30

C.3 The Request Reply Protocol . . . . . . . . . . . . . . . . . . . . . 31C.3.1 Key Transfer . . . . . . . . . . . . . . . . . . . . . . . . . 31

C.3.2 Client Authentication . . . . . . . . . . . . . . . . . . . . 31C.3.3 Getting the Device Details . . . . . . . . . . . . . . . . . 32C.3.4 Commanding the ESS . . . . . . . . . . . . . . . . . . . . 32C.3.5 Logging Off . . . . . . . . . . . . . . . . . . . . . . . . . . 32C.3.6 Exceptional Messages . . . . . . . . . . . . . . . . . . . . 33

C.4 Protocol at a glance . . . . . . . . . . . . . . . . . . . . . . . . . 33

D Device Configuration File Format 34

E Developer Details Writing a client for CSS 36

Bibliography 37

iv

8/7/2019 Tele Byte

7/45

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 . . . . . . . . . . . . . . . . 20A.2 ESS Client Installation Requirements Verification . . . . . . . . . 20A.3 ESS Client Installation Security Warning . . . . . . . . . . . . . 21A.4 ESS Application Login Screen . . . . . . . . . . . . . . . . . . . . 21A.5 ESS Application Settings Dialogue . . . . . . . . . . . . . . . . . 22A.6 ESS Application User Logged In . . . . . . . . . . . . . . . . . 23A.7 ESS Application Change Password . . . . . . . . . . . . . . . . 24A.8 CSS Login Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . 25A.9 Administration Tasks on the CSS . . . . . . . . . . . . . . . . . . 26A.10 Smart Device: Logging in . . . . . . . . . . . . . . . . . . . . . . 26A.11 Smart Device: Authentication Process . . . . . . . . . . . . . . . 27A.12 Smart Device: Controlling Remote Device . . . . . . . . . . . . . 27

B.1 Hardware Circuit Diagram . . . . . . . . . . . . . . . . . . . . . . 28

C.1 CSS-ESS Protocol Overview . . . . . . . . . . . . . . . . . . . . . 33

v

8/7/2019 Tele Byte

8/45

List of Tables

5.1 Division of project work among team members . . . . . . . . . . 115.2 ESS Software Model Element Statistics Summary . . . . . . . . . 125.3 ESS Timeline Summary . . . . . . . . . . . . . . . . . . . . . . . 12

5.4 WebService Timeline Summary . . . . . . . . . . . . . . . . . . . 14

D.1 Device Configuration File Format . . . . . . . . . . . . . . . . . . 35

vi

8/7/2019 Tele Byte

9/45

Chapter 1

Introduction

Computers and the related technologies are becoming more and more ubiqui-tous. Various technical arenas in the field of Computer Science and Engineering,or Information Technology have come very near to the common people. Thenumber of homes with Personal Computers1 is gradually increasing. A day willcome, somewhere in the long future, when PC is referred to in the same classof Food, clothing and shelter. Improvements in the Networking technologieshave fostered growth of very dense networks. Land line telephones have beenbecoming less and less popular and people now prefer communicating while onthe move. ISPs are now laying down their own networks to provide broadbandInternet 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 connectingtheir home appliances to the mobile phone. With this, people would be ableto turn on and off, and to some extent, control the appliances at their homeeven from a distant place. One of the very basic examples of an utility of thisis switching on the air conditioner in the room just some time before reachinghome, so that the room is sufficiently 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 smartdevice. However, this has certain disadvantages.

1. PC are not server systems. They should typically not run server soft-wares.

2. It is necessary that every PC has a global IP address that is recognizedon the Internet. With the current stubborn setup of IPv4 and IPv6 notpicking up momentum, this would be a major challenge. Users woulddefinitely not be ready to shell out a lot of money for a leased IP address.

1Personal computers are referred to as PCs hereafter

1

8/7/2019 Tele Byte

10/45

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 amammoth task.

The problem then is, to install a system that would facilitate many clientsto use its architecture and get their devices online very quickly, inexpensively,and with minimal effort.

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 theutility of any existing setup. Toys, Televisions, Music Players, all have startedhaving a remote control, why not switches?

Users would desire this remote control as a service. They would at a maxi-mum, be ready to pay some service charges but would not be willing to investa lot of money on the pillars of a system that supports this remote access. Asystem that allows many such clients to connect and use the online appli-ance service is definitely desirable. More over, if the system supports manyclasses of devices rather than just appliances, then the system would get moreversatile and can be widely used.

8/7/2019 Tele Byte

11/45

Chapter 2

State of the Art

A Remote Control is perhaps the most popular gadget today. Right from theintense creativity of remotely controlling laser chip markers to the highly de-structive remotely ignitable bombs, from the pins to the planes, remote controlis not only occupying a omnipresence state, but is also enhancing its scope anddomains.

We have had InfraRed Remote Controls, which work over very short dis-tances, and RadioWave Remote Controls, which work over larger distances.However, something fundamentally common with all these controls is that thetransmitter 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 ableto become so popular. The INTERNET is more than just a world wide web.Mobile phones are the gadgets of this generation. Remote control based onInternet 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 specific devices. The need is to writegeneric device control applications.

3

8/7/2019 Tele Byte

12/45

Chapter 3

System Architecture

The happyRC.NET system consists of three main parts, namely the End UserServer System(ESS), the Central Server System(CSS), and the Smart DeviceClient. Figure 3.1 shows the logical structure of these parts, and an outline ofthe 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 users 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 wasa server exporting the device functionality

4

8/7/2019 Tele Byte

13/45


channel(See Appendix C) to talk to the CSS. It has a configuration file that

contains details about the controllable hardware attached to the PC. It is thejob of the ESS to understand commands from the CSS and change the devicestate accordingly.

3.2 CSS

The Central Server System is the heart of the art. It has three roles to play, andtherefore has three components that export various important functionalities.

General Component The General CSS Component is where most of the func-tionality resides. It is the job of this component to receive connectionsfrom various ESS PCs, and maintain their authentication states. Thismaintains a lookup information about exactly which ESS particular usersare connected from, and what the device configuration of their systemis. It shares its memory space with the Remoting component describednext. It is the job of this component to proxy requests from the remotingcomponent to the ESS system, and return the occurrence of a success orfailure.

Remoting Component This component is a stub for .NET Remoting2 calls.It gives a reference to an object which has proxy functions written toallow Remoting clients to call functions of the General Component. Everyconnection to this component instantiates a new object which maintainsthe state (authentication, etc.) of the client. Methods in this object waitfor 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 com-

ponent becomes crucial. It sits on a web server (running IIS) and com-municates to the General Component via the Remoting Component. Thejob of this component is to maintain authentication states over the web.It should ask the Remoting Component to provide the description of theusers device. It should then parse the description out, and display aninterface that can change the device state.

Put together, these components build up the CSS System which can providefacilities for any user to register his device online, and later on, use browsercomplaint 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. Thisinteracts with the CSS and commands the ESS to change the state of theirdevice at a remote location. Figure 3.1 shows two kinds of these clients. Theyare classified on the basis of how thin clients they are.

2.NET Remoting is similar to SunRPC or JAVA RMI3HTTP could be over TCP/IP or WAP

8/7/2019 Tele Byte

14/45


Smart Devices Running Browsers This category includes devices that are

very thin in functionality. Typically, these include mobile phones, WirelessPDAs, etc. They do not have the capability of running large programs,and ship with an operating system that provides a minimal browsing func-tionality. All that these can do is display primary interfaces, and requestsimple form submitted by the users. They need to interact with the WebService component of the CSS in order to facilitate service.

Smart Devices Running CSS Client Some devices have more features thanplain smart devices, and are smarter then we think. Pocket PCs that runoperating systems like Microsoft Windows CE have capabilities of runningcustom programs. A custom made CSS client(See Appendix E) can be in-stalled on these devices so as to customize user interfaces. These devicescan skip the Web Service component and directly interact with the CSS

using .NET Remoting. Clearly, Laptops and Computers are smarter theneven pocket PCs, and they can fall into this category.

3.4 Architecture Notes

The happyRC.NET system uses a Client-Server architectural model. With asecond look, we find that it comprises of a single server that serves multipleclients of two types viz., ESS and smart devices. It should be noted that ESSand smart devices have a one to one relationship and they share the usersidentity in common. Although one ESS can be controlled using many differenttypes of smart clients, two of these clients can not talk simultaneously with thesame ESS, for reasons of atomicity and consistency of operations.

The ESS is connected to the users device using a parallel (LPT1) port. Thiswas preferred over a serial port so that we can work with 8 bits simultaneouslyrather than memorise bits received from the serial port and work once all ofthem are received. This definitely speeds up the operations.

The communication between CSS and ESS works on a Request-Reply proto-col that is encrypted with symmetric cryptography to avoid malicious attemptsof hack, man in the middle, or eavesdrop replay attacks. (See Appendix C.

The General Component and Remoting Component of the CSS share thesame 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 Remotingto access the functionalities of the General Component. Its communication

with the Smart Device is over a simple HTTP channel. Use of HTTPS likeSSL 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.

8/7/2019 Tele Byte

15/45

Chapter 4

How happyRC.NET works

As with almost any other computer based system, the working of happyRC.NETbegins with the process of Installation followed by the successive use. Instal-lation of the ESS on the users PC includes configuration of the device.(SeeAppendix 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 users PC, the users need toget authentication account on the CSS. Once the request for a new identityon the CSS is granted by the administrator, an entry of the username and itscorresponded 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 theCSS and verifies their identity. Having done that, the CSS requests the ESS tosend the device details. The CSS parses the configuration file into an serializedobject and sends it over to the CSS. The device is now ready to be remotelycontrolled

4.3 Showing Device State Change Interface

The users on the smart clients need to be given an interface for changing thedevice state. To facilitate this, the client request the CSS to send them thedevice configuration details. These details are parsed based on the type andgroups of inputs and the interface is displayed.

4.4 Calculating New State Numbers

The device states are classified into groups. For every group, there is a unionpolicy, like AND, OR, XOR. Every state is represented by a byte, and when in

1The database could well be a flat file.

7

8/7/2019 Tele Byte

16/45


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 specified in the configuration file, a new state number

is calculated. These state numbers are ordered by their group numbers, say1,2,3, and stored for further processing.

Group Zero is a special group, where there is no union policy. Every state inthis group is sent as if it were in an independent group and the state numbersof 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 requestto the ESS which does the actual action of writing the command to the parallelport. Based on whether the action returned success or failure, the users needto be notified.

4.6 Logging Off

When the users log off from the smart clients, no significant state changes occurin the CSS. The ESS still remains connected, and users can again use the smartclient for further communication with device.

However, when the uses log off from the ESS, the CSS discards all dynamicentries 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 minutedetails that need to be described in order to understand how exactly the systemproceeds with the work flow. Figure 4.1 shows an activity flow diagram of thesystem.

Here is an enumerated description of the activities. The enumeration showsthe primary activity flow. The flow might change a little in certain extendeduse cases.

1. The user interface of the ESS system would be used by the user to enterhis authentication credentials.

2. The ESS program would set up a communication channel with the CSS,thereby connecting and verifying the users details.

3. If the authentication succeeds, the user is notified that his device is readyto be controlled remotely.

4. The ESS program parses the devices configuration file, and converts itinto objects describing the functionality of the device.

8/7/2019 Tele Byte

17/45


Figure 4.1: Overall Activity Flow Diagram

5. ESS communicates the details of the device to the CSS on the alreadyestablished 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 functionsfor the device, on the web service, to be remotely invoked.

7. The CSS maintains a table containing entries of which authenticated useris 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 authenti-cation details to the user.

10. The client calls the initialize function on the CSS by parameterizing itwith the authentication details.

11. The CSS verifies the authentication and if the client is affirmatively iden-tified, it sends the device description to the client, along with the currentstate of the device, if asked.

12. The client extracts a form out of the obtained description and displays itto the user.

13. If the user suggests any changes in the form, the client parses thosechanges, and categorizes them into batch requests to the server, dependingon the action groups.

8/7/2019 Tele Byte

18/45


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 keepsasking user for further change in the circuit. The user can choose to logoutor 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 ESSapplication. 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 ESSapplication.

8/7/2019 Tele Byte

19/45

Chapter 5

Design Issues

In this chapter, we would give details about how the project was conceived andbuilt, i.e. the Analysis and design phase. Because the project team consists offour members, the work was distributed in blocks of modules as described inTable 5.1.

Table 5.1: Division of project work among team membersModules Primary Assignment Person Hardware Circuit Varun KhullarESS Client, Security Parlikar Alok UlhasCSS (General Component) Shubham Shrestha AgrwalCSS (Web Service), Architecture Nishant Shrivastava

Because the modules have been designed almost independently, the designissues 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 theparallel port. The Managed Runtime of the .NET platform that was beingused to develop the project does not allow unsafe I/O calls like this, andhence a DLLImport followed by a call to one of the entry points in the

DLL was to be performed. The Windows documentation mentions howthe Kernel API can be used to interact with external devices.[Mic03]

The other essential thing was to tell the software, details of the hardwareconnected. To do this, a configuration file format was formulated. Theformat allows access to devices with up to 256 states. More details of theformat can be found in Appendix D.

Communicating with the CSS This task involved formulating a protocolthat 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-ficiently strongly encrypted can be found in Appendix C.

11

8/7/2019 Tele Byte

20/45

8/7/2019 Tele Byte

21/45


5.2 CSS Server Design

The CSS Server has following functions to perform:

Interacting With the ESS The implementation of the protocol formulatedwith the ESS was an obvious task. However, certain issues which dif-fered from the ESS was the presence of multiple ESS clients. To takecare of many clients, the CSS had to be implemented as a state machinebased program. Asynchronous read functions were made for robust statemachine.

Communicating via .NET Remoting .NET remoting was used to exportthe functionality of the General CSS component to the smart client world.TCP channel is used for the communication. The exported functionalityis documented in Appendix E.

The user Interface The task involved creating the GUI for the user to in-teract with the system. The GUI is also implemented as a state basedmachine.

The CSS was designed using the prototyping principle. A basic prototype wasfirst 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 dontwant to go into the technical details and yet reap the benefits of technologi-cal advances to their benefits.This basic aim couldnot have been fulfilled if itrequired some expensive WindowsCE enabled mobile phone which costs some-thing in excess of 40,000 rupees to remotely controll the users home appliances.Therefore the method to be implemented on the mobile devices had to be some-thing on the lines of a web service which could be access from any Internetenabled mobile phone.

Choice of Technology to use

Initially, we felt we would encounter some grave problems in correctly identifyingthe Mobile Device device making the request , whether it is a PDA, WAP

enabled mobile phone or the ultimate smart device a computer and reply tothe request in the suitable format .i.e WML if the requesting agent is a WAPenabled Mobile phone, HTTP if the request comes from a Laptop or a Computeror in a format compatible with PDAs. But after some reading in this directionwe discovered that we need not worry that much because ASP .Net providedmobile controls and all we needed was to make a .Net Mobile page and the IISserver would do the task of identifying the requesting agent and generate theoutput in the suitable format. Connection to a web server was practical solutionalso because it allows users to connect from any place which has Internet Accessand also to do away with the need of the end systems to have a static IP address.

8/7/2019 Tele Byte

22/45


Interaction with the CSS

The basic interface was made in ASP.Net using Mobile controls with C# as thescript powering the ASP.Net page.The interaction with the CSS was using .NetRemoting by creating a Client Activated Object over a TCP channel with theCSS.[Gri02]

Backend Implementation Summary

A .Net Remoting Client Activated TCP channel is created with the CSS assoon as the user provides his login ID and password. If the username and thepassword match with those in the Database at the CSS, the user is successfullyauthenticated. The CSS on request transmits to the Web Server data about thestate of the Users ESS and the groups and the policy associated with groups

of the Users appliances. After receiving the request of the user, as to whatchanges he wishes to make to the final state of the appliances, the final stateof the end System is calculated and the words to output to the end system aretransmitted to the CSS which in turn sends the data to the ESS.

Table 5.4: WebService Timeline SummaryTask Name Start Date Duration(Days) E nd DateAnalysis of Software 6/8/04 8 15/8/04Basic Use Cases 16/8/04 2 Thu 17/8/04Coding Implementation Wed 12/9/04 13 Tue 26/9/04Minute Design Changes Fri 24/10/04 3 Tue 28/10/04Testing/Debugging Tue 28/10/04 4 Mon 1/11/04

Deployment Ready Wed 1/11/04 2 Fri 4/11/04

8/7/2019 Tele Byte

23/45

Chapter 6

Specific Technologies used

6.1 .NET Framework

The .NET Framework is a new computing platform that simplifies applicationdevelopment in the highly distributed environment of the Internet.[Mic03] The.NET Framework is designed to fulfill the following objectives:

To provide a consistent object oriented programming environment whetherobject code is stored and executed locally, executed locally but Internet-distributed, or executed remotely.

To provide a code-execution environment that minimizes software deploy-ment and versioning conflicts.

To provide a code-execution environment that guarantees safe executionof code, including code created by an unknown or semi-trusted third party.

To provide a code-execution environment that eliminates the performanceproblems of scripted or interpreted environments.

To make the developer experience consistent across widely varying typesof applications, such as Windows-based applications and Web-based ap-plications.

To build all communication on industry standards to ensure that codebased on the .NET Framework can integrate with any other code.

The .NET Framework has two main components: the common languageruntime and the .NET Framework class library. The common language runtimeis the foundation of the .NET Framework. One can think of the runtime asan agent that manages code at execution time, providing core services such asmemory management, thread management, and remoting, while also enforcingstrict type safety and other forms of code accuracy that ensure security androbustness. In fact, the concept of code management is a fundamental principleof the runtime. Code that targets the runtime is known as managed code, whilecode that does not target the runtime is known as unmanaged code. The classlibrary, the other main component of the .NET Framework, is a comprehen-sive, object-oriented collection of reusable types that you can use to develop

15

8/7/2019 Tele Byte

24/45


applications ranging from traditional command-line or graphical user interface

(GUI) applications to applications based on the latest innovations provided byASP.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 ofmanaged code, thereby creating a software environment that can exploit bothmanaged and unmanaged features. The .NET Framework not only providesseveral runtime hosts, but also supports the development of third-party runtimehosts.

6.1.1 The Common Language Runtime

Compilers and tools expose the runtimes functionality and enable you to writecode that benefits from this managed execution environment. Code that you

develop with a language compiler that targets the runtime is called managedcode; it benefits from features such as cross-language integration, cross-languageexception handling, enhanced security, versioning and deployment support, asimplified model for component interaction, and debugging and profiling ser-vices.

To enable the runtime to provide services to managed code, language com-pilers must emit metadata that describes the types, members, and referencesin your code. Metadata is stored with the code; every loadable common lan-guage runtime portable executable (PE) file contains metadata. The runtimeuses metadata to locate and load classes, lay out instances in memory, resolvemethod invocations, generate native code, enforce security, and set run-timecontext boundaries.

The runtime automatically handles object layout and manages references toobjects, releasing them when they are no longer being used. Objects whoselifetimes are managed in this way are called managed data. Garbage collectioneliminates memory leaks as well as some other common programming errors. Ifyour code is managed, you can use managed data, unmanaged data, or bothmanaged and unmanaged data in your .NET Framework application. Becauselanguage compilers supply their own types, such as primitive types, you mightnot always know (or need to know) whether your data is being managed.

The common language runtime makes it easy to design components and ap-plications whose ob jects interact across languages. Objects written in differentlanguages can communicate with each other, and their behaviors can be tightlyintegrated. For example, you can define a class and then use a different languageto 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 adifferent language. This cross-language integration is possible because languagecompilers and tools that target the runtime use a common type system definedby the runtime, and they follow the runtimes rules for defining new types, aswell as for creating, using, persisting, and binding to types.

6.2 .NET Remoting

.NET remoting enables the programmer to build widely distributed applicationseasily, whether application components are all on one computer or spread out

8/7/2019 Tele Byte

25/45


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 reachableover its network. One can also use .NET remoting to communicate with otherapplication domains in the same process.

.NET remoting provides an abstract approach to interprocess communica-tion that separates the remotable object from a specific client or server appli-cation domain and from a specific mechanism of communication.[Mic03] As aresult, it is flexible and easily customizable. One can replace one communicationprotocol with another, or one serialization format with another without recom-piling the client or the server. In addition, the remoting system assumes noparticular application model. One can communicate from a Web application, aconsole application, a Windows Service from almost anything one wants to use.Remoting servers can also be any type of application domain. Any applicationcan host remoting objects and provide its services to any client on its computer

or network.

8/7/2019 Tele Byte

26/45

Chapter 7

Conclusion and Future

Scope

In this report, we described happyRC.NET as a project that helps us talk todevices that are connected to a remote computer. A careful implementation ofthe idea suggested by the project can prove to be very beneficial in promotinghome automation and similar activities. This project can be considered as aproof of concept the concept that it is possible to mobilize the control ofappliances.

What this project does in the ESS, i.e. interaction with the hardware, couldas well be performed on an embedded system. Agreed, IPv6 is taking time togain 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 ESSof its own, to make life of people even more easier. What is a Remote Controltoday, would get replaced by a Mobile Control.

This project lacks support for devices that have more than 256 states. Moreover, this can control only state based devices. There are some devices that areactivity based, not state based. For most needs, changes in the configurationfile format would suffice for getting a proper support for the required device.For example, these changes could be adding new action types, or more grouppolicies, etc. However, in rare cases, the application might have to be slightlyrestructured.

18

8/7/2019 Tele Byte

27/45

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 efforts were made to keep the ESS Client as light as possible, it stillhas 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 clienthas been deployed as a Click Once application. The deployment folder wouldcontain 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 file Setup.exe.

3. If you get a screen as shown in Figure A.1, please read the license carefullyand click the Accept button to proceed. This error had come because youhad not installed the .NET Framework 2.0, and hence, it required to be

1It is possible to port the client to other operating systems like Linux, however the appli-cation as a part of this project compiles, but does not run on Linux

19

8/7/2019 Tele Byte

28/45


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 itwould show a progress splash screen as shown in Figure A.2.

Figure A.2: ESS Client Installation Requirements Verification

5. If you get a dialogue as shown in Figure A.3, you must be running thesetup from a network location. Make sure you have copied the installationfiles to your local system.

6. If your system had met the requirements of the application, it would getsuccessfully installed. A shortcut would be added to the Start Menu, atthe location All Programs -> IIITA. You can use this shortcut to runthe application.

7. Just after the installation, the application would start running. You mayproceed to start using the same.

8/7/2019 Tele Byte

29/45


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 shortcutwould 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

8/7/2019 Tele Byte

30/45


Changing the Settings

Before using the program, you must know the location of the CSS server andthe location of the configuration file for your device. To change the existingsettings,

1. From the Login screen, (Figure A.4) click the Change Settings link. Youwould be presented with a form that looks as in Figure A.5.

Figure A.5: ESS Application Settings Dialogue

2. Enter the CSS servers IP address or host name in the first field.

3. Enter the CSS servers port number (default: 8221) in the second field.

4. In the third field, select the location of the device configuration file onyour system.

5. Once you click the Update button, the application would try to verify thesettings. If any of the settings is incorrect, a red blinking icon would beplaced next to that field. 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 thelogin 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 thepassword can not be blank.

8/7/2019 Tele Byte

31/45


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 notification ofthe same.

4. If the authentication times out, you would be notified about the same too.You may then try authenticating again.

5. If the authentication is successful, the application displays the LoggedIn 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 wouldtake you to the Logged In screen(Figure A.6).

2. Click the Change Password link. You would be taken to the passwordchange interface as shown in Figure A.7.

3. Enter the old and new passwords. Also enter the new password again, forconfirmation, and click the Change button. If the password change wassuccessful, 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 iconwould be displayed on the screen which would show the exact error onhovering the mouse over it. Please read the error and take the suggestedcorrective action.

8/7/2019 Tele Byte

32/45


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 confirmation during logout. Click OK to continuewith 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 allowsmany end users to connect to the their devices attached through the ESS. Thissection 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 requiredthat the underlying OS of the system supports this heavy network load. Hereis 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) whereAdministrator can Log on. After logging in the user has option of starting

8/7/2019 Tele Byte

33/45


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 ofclient 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 as-signed, the system would log you in.

Logging out

The application would log the administrator out at the click of the Logoutbutton.

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 dont close the application oryou 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 Serverbutton to stop the server.

8/7/2019 Tele Byte

34/45


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 users 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 andgenerates proper messages reflecting the state of the connection. The user isasked to authenticate at the first page where he sees a Login Screen promptingfor a Username and a Password to initiate the communication. (See FigureA.10)

Figure A.10: Smart Device: Logging in

8/7/2019 Tele Byte

35/45


If Authentication fails, he is asked to re-enter his username and password.

On Authentication with a valid Username and Password, he can choose eitherto change his password or to Control the devices thus fulfilling his dream ofHome Automation. See Figure A.11

Figure A.11: Smart Device: Authentication Process

On successful change of password, user is asked to relogin with the newpassword. If he selects to Control his devices screen generates the list of theappliances connected to his end system and by means of checkboxes and Textinput, he inputs the final state of the end system device. On selecting theselection Option, the device List is shown on the Mobile Screen. User makes hisselection 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 securelylog out from the control interface.

8/7/2019 Tele Byte

36/45

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 different aplliances. Theparallel port gives a potential of 3.3v to 3.5v which has been used to drive theoptocoupler. The optocoupler is used as a switch for a 12v DC supply (givenby a transformer). This 12V is being used to Switch on the relay. The relay isconnected to 220 volts AC power supply. This power supply is now controlledby 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

8/7/2019 Tele Byte

37/45

Appendix C

CSS-ESS Protocol Details

This Appendix mentions details about the protocol that the CSS and ESS useto talk to each other. A one liner description of the protocol is Request Replyprotocol over Encrypted TCP/IP Channel. The following sections explain howdifferent issues are tackled in the protocol.

C.1 Getting Connected

The CSS has a General Component that listens to a specific TCP port onthe server machine. The ESS Client must know this port number in order toestablish a connection. Having known the same, it establishes a regular TCPconnection 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 likeDES are used to encrypt and decrypt a given text, and this shared key is requiredfor the purpose. In Asymmetric Cryptography, every entity has a pair of keyscontaining, one public key and other private key. Algorithms like RSA are usedto encrypt the text. To send encrypted data to someone, his public key is usedin 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 presentsa problem. Sharing the key becomes a crucial issue. One has to create this keyand send it to the other. If some person taps their connection, the beauty ofthis algorithm gets pretty useless. Sharing keys1 is quite better with public keycryptography, one just needs to send the public key. However, there still presentproblems of security attacks.

1Generally, the encryption algorithms used are symmetric, but the key transfer is done byencrypting the symmetric key in a public key encryption.[Sta02]

29

8/7/2019 Tele Byte

38/45


C.2.2 Security Attacks

Trivial Network Tapping

This kind of an attack can occur if the symmetric key is transferred over aninsecure channel. Once an evesdropper gets hold of the key, all algorithmsbecome very useless.

Log and Replay

Algorithms that have their keys hard coded are vulnerable to this attack. Be-cause the key for their encryption and decryption are same at all times, anevesdropper can record a transaction between two parties by tapping the net-work 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. Theother party can not distinguish between the initial transaction and the replayattack.

Man in the Middle

The biggest problem even with public key cryptography is this attack. Instead ofjust tapping the network line between two parties, the evesdropper this time sitsin between them. Right from when the key transfer takes place, this evesdropperproxies the connection between the parties, and also proxies for the public keys.He can thus not only understand the conversation between the parties, but alsochange 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 implemen-tation of this system. A synopsis of the encryption algorithms is explainedfollowed 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 fixed, but is generated dynamically.

The key is generated from two salts a random string, and the userspassword.

Defense against Attacks

It is important to note the following.

The users password is known to the ESS as the user is going to enter itfor authentication purposes.

2.NET provides a class for the same.

8/7/2019 Tele Byte

39/45


The users password is known to the CSS because it has a password

database. No one else knows the users password. (The user is supposed to keep it

secret)

A Symmetric Cryptography algorithm begins with sharing of the key. Thekey that we are using is generated from two parts, one of which is known toboth the ESS and CSS. After the connection, CSS generates a random stringand transmits it plain text to the ESS. Using this string and the password, bothof them generate a shared key.

1. Because any evesdropper does not know the users password, even if hereads the random string, he can not generate the key that is shared byCSS and ESS.

2. Because the generated key depends on a random string, which ought tobe different for every connection, the shared key is different for everyconnection, and thus, the evesdropper can not replay his transaction logonto the network.

Thus we see that the attacks of tapping, Log-Replay and man in the middle aredefended 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 encryptedmessage, and any message that is transferred plain text is written in SlantedText. 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 first messages betweenthe systems is as follows:

ESS: KEY userNameCSS: KEY 50meR4nd0m5+r1ng

When CSS receives the username, in the first message, it first calculates arandom string and sends it back to ESS. It then retrieves the users passwordfrom the database and using this and the random string, generates the shared

key. When ESS gets the second message, it uses the user provided passwordand this random string to compute the shared key. Thus, at the end of thistransaction, 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 different keys.This is handled during the authentication

C.3.2 Client Authentication

After the key transfer, the ESS proceeds with the authentication and the fol-lowing dialogue takes place:

8/7/2019 Tele Byte

40/45


ESS: AUTH userName pA55w0rd

CSS:OK

ORESS: AUTH userName pA55w0rdCSS: ERR

The ESS sends an encrypted text containing the username and passwordof the user. If the password was correct, the message could be decrypted bythe CSS. In such a case, it would reply with a plaintext OK saying that theauthentication is done. If it is not able to decrypt, it understands that the ESShad a different shared key because the user entered incorrect password, andhence returns ERR in plain text.

Note: The CSS replies to the authentication request in plain text. This wasnecessary because if the user has entered incorrect password, it would not beable to decrypt even the ERR response, and there would be a infinite loop in

the state machine.

C.3.3 Getting the Device Details

After successful authentication, the CSS requests the ESS to send it the descrip-tion 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: DESCESS: DESC base-64 encoded serialized object

The serialized object is typically XML, and contains many line breaks. Inthe protocol, every message terminates with a linefeed, and thus, the serializedtext can not be passed as it is. Hence, the base 64 encoding is applied to thesame.

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 dialoguethat takes place.

ESS: WRITE byteCSS: OK

ORESS: WRITE byteCSS: 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 theport fails. For example, if someone maliciously tried to write a number withvalue more than 255 (maximum for a byte), then this call would fail, and ESSwould reply in an error.

C.3.5 Logging Off

The user on the ESS may choose to log his client off. It is the job of the ESSto notify the CSS about the action and then close the network connection.

ESS: OFF

8/7/2019 Tele Byte

41/45


The ESS closes the socket immediately after this transfer. The CSS should

close its end too, after it gets the notification.

C.3.6 Exceptional Messages

It might happen that even after the proper authentication, etc. of the ESS withthe CSS, some error might creep in. This should not happen with the actualclients, but some malicious hacker might attempt sending messages that areout of context. To handle such situations, the CSS sends the following messagewhenever it does not understand what the message was.

CSS: EMERGENCYNote that an invalid operation usually results in just ERR. Only in certain

exceptional cases, like invalid description will this message be used. The CSSwould close the connection after sending this message. The ESS notifies 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 agraphical overview of the protocol.

Figure C.1: CSS-ESS Protocol Overview

8/7/2019 Tele Byte

42/45

Appendix D

Device Configuration File

Format

This Appendix discusses the format for the file that specifies details about thehardware connected to the ESS. This Configuration File can be located anywhere on the system that has ESS installed. Path to the correct file can be setfrom the ESS program.

This Configuration File is a tab separated text file. There are two sectionsin the file.

The first section stores information about the various Actions that can beperformed on the devices. Every record in this section contains four fields, asfollows:

Byte This is the byte word that has to be written on the parallel port so as toperform that action.

Type This specifies 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 isassumed that with numeric inputs, the request would be repeated specifiednumber of times to carry out the action.

Description This is a string field which would be displayed to the user. Thisshould be terse, nonetheless, very descriptive, because the user should beable to identify this action completely.

Group Actions can be grouped together. All actions of the same group have

this field value the same. This field contains integer values 1,2,. . . ,n. Theremight be some actions that can not be grouped. Group number 0 is usedfor such actions.

The second section stores information about the various Groups. We hadclassified actions into groups in the earlier section. There has to be a policyso that the bytes for those actions can be combined. This section defines thepolicy. Every policy is one character out of | & ^ which represent OR, AND andXOR 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 begenerated by performing bitwise or of the bytes of the actions A, B and C. The

34

8/7/2019 Tele Byte

43/45


file should ideally not contain a newline at the end of file, although that would

result in no fatal error.These two sections need to have a delimiter that is a sentinel to the file. Forthis purpose, a line with just ### as the text is used. Table D.1 specifies ageneral structure of the file.

Table D.1: Device Configuration File FormatByte1 Type1 Description1 Group1Byte2 Type2 Description2 Group2Byte3 Type3 Description3 Group3

......

......

###Group1 Policy1Group2 Policy2Group3 Policy3

......

EOF

8/7/2019 Tele Byte

44/45

Appendix E

Developer Details Writing

a client for CSS

The Client for the .Net Remoting Service depends on the type of server runningthe Remoting Service.

In order to implement the .Net Remoting Client, we need to use the classesSystem.Runtime.Remoting and System.Runtime.Remoting.Channels.

Because the architecture of the CSS supports many clients to one server, useofServer activated objects is not possible. Client-activated objects are analogousto 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 maintainstates (like authentication information) in the same.

The Remoting Component of the CSS exports the following functionality forthe clients:

Authenticate(username,password) Returns true if the user was properlyauthenticated.

Get Config() Returns an object containing the configuration of the device.This object belongs to class ConfigData and details about the same canbe found in the code documentation.

Write Word(byte) Attempts to write the given byte as a state to the deviceconnected to the ESS. Returns success or failure as a boolean.

Change Password(old, new) Attempts to change the users password and

returns a boolean that describes success or failure.

Get LastByte() Returns the byte that was last written to the ESS client.

Logoff() Sets the authentication state to false.

36

8/7/2019 Tele Byte

45/45

Bibliography

[Gri02] Fergal Grimes. Microsoft .NET for Programmers. Manning Publica-tions Co., 2002.

[Lam03] Leslie Lamport. LATEX - A document preparation system. PearsonEducation, 2 edition, 2003.

[Mic03] Microsoft. MSDN Documentation, 2003.

[Sta02] William Stallings. Cryptography and Network Security. Pearson Edu-cation Asia, 2 edition, 2002.

[Tan00] Andrew S. Tanenbaum. Computer Networks. Prentice Hall of India,2000.

Tele Byte

Documents