project Report on LAN Security Manager

A

Minor Project Reporton

LOCAL AREA NETWORK MANAGER

Submitted in Partial Fulfillment of

the Requirements for the Degree

of

Bachelor of Engineering

in

Computer Engineering

to

North Maharashtra University, Jalgaon

Submitted by

Shahrukh Mohd Ayyaz Khan

Under the Guidance of

Miss Prachi Chaudhari

DEPARTMENT OF COMPUTER ENGINEERING

SSBT’s COLLEGE OF ENGINEERING AND TECHNOLOGY,

BAMBHORI, JALGAON - 425 001 (MS)2014 - 2015

SSBT’s COLLEGE OF ENGINEERING AND TECHNOLOGY,

BAMBHORI, JALGAON - 425 001 (MS)

DEPARTMENT OF COMPUTER ENGINEERING

CERTIFICATE

This is to certify that the minor project entitled Local Area Network Manager, sub-

mitted by


in partial fulfillment of the degree of Bachelor of Engineering in Computer Engineering

has been satisfactorily carried out under my guidance as per the requirement of North

Maharashtra University, Jalgaon.

Date: April 8, 2015

Place: Jalgaon

Miss Prachi Chaudhari

Guide

Prof. Dr. Girish K. Patnaik Prof. Dr. K. S. Wani

Head Principal

SSBT’s College of Engineering and Technology, Bambhori, Jalgaon (MS) i

Acknowledgements

Apart from the my efforts the success of any work depends largely on the encouragement

and guidelines of many others. We take this opportunity to express my gratitude to the

people who have been instrumental in the successful completion of this Minor project work.

We would like to express my heartfelt gratitude towards our Guide Assi Prof. Miss Prachi

Chaudhari for his support and valuable guidance which resulted in the successful completion

of this report.We would like to express my sincere gratitude to Head of Department Prof.

Dr. Girish K.Patnaik (Department of Computer Engineering), for his valuable guidance and

encouragement during the work.We would like to take opportunity to sincerely thanks to all

the concern individuals, family members, friends, who made my Spacial study success. We

also thanks all those people who helped me in anyway what so ever act some point in time.


SSBT’s College of Engineering and Technology, Bambhori, Jalgaon (MS) ii

Contents

Acknowledgements ii

Abstract 1

1 Introduction 2

1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.2 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.3 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.4 Problem Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.5 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.6 Objective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.7 Organization of the report . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.8 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2 System Analysis 5

2.1 Literature Survey . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.2 Proposed System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.3 Feasibility study . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.3.1 Economical Feasibility . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.3.2 Operational Feasibility . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.3.3 Technical Feasibility . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.4 Risk Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.5 Project Scheduling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.6 Effort Allocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.7 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3 System Requirement Specification 10

3.1 Hardware requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3.2 Software requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3.3 Functional requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.4 Non-Functional requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

SSBT’s College of Engineering and Technology, Bambhori, Jalgaon (MS) iii

3.5 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

4 System Design 12

4.1 System Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

4.1.1 Interfaces: The Heart of RMI . . . . . . . . . . . . . . . . . . . . . . 12

4.1.2 RMI Architecture Layers: . . . . . . . . . . . . . . . . . . . . . . . . 13

4.1.3 Stub and Skeleton Layer: . . . . . . . . . . . . . . . . . . . . . . . . . 14

4.1.4 Remote Reference Layer: . . . . . . . . . . . . . . . . . . . . . . . . . 14

4.1.5 Transport Layer: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

4.2 E-R diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

4.3 Database Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

4.3.1 Schema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

4.4 Data Flow Diagram (up to level-2) . . . . . . . . . . . . . . . . . . . . . . . 17

4.5 Interface Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

4.5.1 User Interface Design . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

4.5.2 Module to Module Interaction (Using Collaboration Diagram) . . . . 18

4.6 Uml Diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

4.7 Use Case Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

4.7.1 Class Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

4.7.2 Sequence Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

4.7.3 Component Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

4.7.4 Deployment Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

4.7.5 State Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

4.7.6 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

5 Implementation 27

5.1 Implementation details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

5.1.1 Pd detection: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

5.1.2 Files /folder/application . . . . . . . . . . . . . . . . . . . . . . . . . 28

5.2 5.2 Implementation environment . . . . . . . . . . . . . . . . . . . . . . . . . 28

5.3 5.3 Flow of system development . . . . . . . . . . . . . . . . . . . . . . . . . 28

5.4 5.4 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

6 System Testing 31

6.1 TESTING STRATEGIES: . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

6.1.1 White-box tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

6.1.2 Black-box tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

6.1.3 Unit Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

SSBT’s College of Engineering and Technology, Bambhori, Jalgaon (MS) iv

6.1.4 Integration Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

6.1.5 Validation Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

6.1.6 System Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

6.1.7 Alpha and Beta Testing . . . . . . . . . . . . . . . . . . . . . . . . . 33

6.1.8 Black-Box Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

6.2 Test cases and Test Results: . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

6.3 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

7 Results and Analysis 35

7.1 Result . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

7.1.1 Enter IP address: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

7.1.2 Connection successful . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

7.1.3 Functional Menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

7.1.4 Pen drive detected . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

7.1.5 Snapshots of client desktop . . . . . . . . . . . . . . . . . . . . . . . 36

7.1.6 Path of .exe file to lock application . . . . . . . . . . . . . . . . . . . 36

7.1.7 Application Locked . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

8 Conclusion and Future Scope 40

8.1 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

8.2 Future Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

Bibliography 41

SSBT’s College of Engineering and Technology, Bambhori, Jalgaon (MS) v

List of Figures

2.1 serverclient . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.2 Gantt chart of LAN Manager . . . . . . . . . . . . . . . . . . . . . . . . . . 8

4.1 fig. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

4.2 fig.2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

4.3 fig.3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

4.4 fig.4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

4.5 fig.5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

4.6 fig.6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

4.7 User interface component tree . . . . . . . . . . . . . . . . . . . . . . . . . . 17

4.8 fig . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

4.9 Event Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

4.10 Collaboration Diagram between Modules . . . . . . . . . . . . . . . . . . . . 20

4.11 Use Case Diagram for LAN Manager . . . . . . . . . . . . . . . . . . . . . . 21

4.12 Internal Use Case Diagram for LAN Manager . . . . . . . . . . . . . . . . . 22

4.13 Class Diagram for LAN Manager . . . . . . . . . . . . . . . . . . . . . . . . 23

4.14 Sequence Diagram for LAN Manger . . . . . . . . . . . . . . . . . . . . . . . 24

4.15 Component Diagram for LAN Manager . . . . . . . . . . . . . . . . . . . . . 25

4.16 Component Diagram for LAN Manager . . . . . . . . . . . . . . . . . . . . . 25

4.17 State Diagram for LAN Manager . . . . . . . . . . . . . . . . . . . . . . . . 26

5.1 Task network for Implementation . . . . . . . . . . . . . . . . . . . . . . . . 29

7.1 fig. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

7.2 fig. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

7.3 fig. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

7.4 fig. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

7.5 fig. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

7.6 fig. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

7.7 fig. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

SSBT’s College of Engineering and Technology, Bambhori, Jalgaon (MS) vi

Abstract

This project deals with the functionalities of the terminal systems connected through a

network. This enhances the work efficiency of the administrator and also reduces the phys-

ical work strain. It can also be used to reduce the unnecessary power consumption in an

organization.

Collaborative architecture brings serious security challenges. One of these collaborative

solution is a remote desktop that provides a virtual graphical environment through a network

displayed on a thin client. As several thin clients access to the same host, conflicts or non

interference problems can raise.

SSBT’s College of Engineering and Technology, Bambhori, Jalgaon (MS) 1

Chapter 1

Introduction

1.1 Introduction

We have seen many places where we have local area networks and lots of people using them

as per their own needs. In such scenarios we have to closely monitor the computers. Many

a times we need to lock the resources such as drives, folders or files on these computers to

restrict the users of making use of them.These are the common task that we do in our day to

day life but for this we dont have utility software. LAN Manager aims to develop a software

system that will be used as a remote control for PCs connected in a Local Area Network, this

software will be able to lock various resources such as Files, Folders, Applications, external

devices control and will also control the processes that are running on the remote computer.

This system does not connect to the machine but still can control its resources to lock or

unlock them. This way it save the processing powers of both the server and client computers,

thus speeding up the process.

1.2 Background

In the present generation systems, there is a need for the administrator has to go all around

the network in order to terminate any system that is left non-terminated.The administrator

has to take all the trouble of going to a particular system to access a file that is needed by

him.In order to get the system configuration details of any particular system, the admin-

istrator has to take the trouble of going to that system for obtaining the information.The

processes that are running in a particular system can be viewed only in that system itself

by using the present generation softwares.


1.3 Motivation

In todays corporate world environment we find many local area networks and lots of people

using them as per their own needs. In such scenarios we have to closely monitor the comput-

ers. In order manage such scenario we used to go to each and every individual machine in

the network and monitor it. There is no way to do it from a single server which is connected

in the same local area network. There is no way to impose rules from a remote server. We

also had windows utility called as a remote desktop connection that gives us the ability to

remotely connect to a computer/PC in network, after getting connected to the computer

the screen of the computer appears on the machine from where we are connecting. After

successful connection we can control the PC as if its our PC and we are controlling it with

our keyboard and mouse. But these windows utility increases processing powers and can be

error prone. Java LAN manager for distributed object systems aims to develop a software

system that will be used as a remote control for PCs connected in a Local Area Network, this

software will be able to lock various resources such as Files, Folders ,Applications, external

devices control and will also control the processes that are running on the remote computer.

This system does not connect to the machine but still can control its resources to lock or

unlock them. This way it save the processing powers of both the server and client computers,

thus speeding up the process.

1.4 Problem Definition

Previously, we used to go to each and every individual machine in the network and lock

the resources on it. There is no way to do it from a single server which is connected in the

same local area network. There was no way to impose these rules from a remote server. We

also had windows utility called as a remote desktop connection that gives us the ability to

remotely connect to a computer/PC in network, after getting connected to the computer

the screen of the computer appears on the machine from where we are connecting. After

successful connection we can control the PC as if its our PC and we are controlling it with

our keyboard and mouse. But this windows utility is completely different from our system

as we do not connect to the machine but still can control its resources to lock or unlock

them. This way it save the processing powers of both the server and client computers, thus

speeding up the process.


1.5 Scope

The most important scope of the software is to control all the computers in the network for

locking and unlocking of resource and application .Ability to save the settings for individual

computers in the local area network as profiles which will save the efforts to each time repeat

locking/unlocking the same resources on different computers again and again. User friendly

graphical interface of the system.

1.6 Objective

Project mainly aims to write a software system that is used as a remote control for PCs

connected as a Local Area Network, this software is used to lock various resources such as

Drives, Folders, Files, Applications and Data Files, and it also control the processes that

are running on the remote computer. The software system also controls the login/logoff and

shutdown/restart events. The software has the ability to lock the USB as well as Removable

Drives. The software also to keep an eye on clients desktop i.e we can see what client is

doing on his desktop.

1.7 Summary

In this chapter, discussion about introduction to our project has been done. Next chapter

will discuss about System analysis


Chapter 2

System Analysis

2.1 Literature Survey

The File Transfer Protocol (FTP) is the most common technique for file transfer over the

Internet. FTP is a standard network protocol used to transfer files reliably from one host to

another over a Transmission Control Protocol/ Internet Protocol (TCP/IP) based network.

[7].The FTP runs on the upper layers of the OSI model and uses the Transport Control

Protocol (TCP) to transport the transferred files. The TCP is a connection-oriented protocol

that resides at layer 4 of the OSI Model. It provides extensive error control and flow control

to ensure that data is delivered successfully [8]. For file transfer to be successful via FTP,

a client software/application needs to be in place, connected to a server application which

listens to commands from the client. This client application is expected to run on individual

computer which will be connected to the server via networks, be it Internet or Intranet

[9,10,11]. The server is identified by a text name or an IP address.

A proposed an ALL IN ONE solution which overcomes above limitations[1]. This is

achieved by using existing technologies VNC (Virtual Network Computing), which is having

Remote Frame Buffer Protocol, RFB as its underlying technology [1][5]. Sockets are used

for inter-process communication. Socket API is especially provided by the operating system

allowing application programs to control and use network sockets [2][3]. File descriptor for

network communication is got through a call to the socket () system routine, which returns

the socket descriptor. Communication is done through it using the specialized send () and

recv () socket calls.Sockets deliver the incoming data packets to specific process or thread

of an application. Server is the computer application that provides application services. It

creates sockets on start up in listening mode [2] [7]. Once listener is run, all it does is to sit

there and listen whether a packet arrives or not. Similarly many functions are there which

are said to block, i.e. if there is no data, they sleep there until some data arrives. Such

functions are accept (), recv ().


Figure 2.1: Socket Programming

2.2 Proposed System

An normal LAN Manager only is use to share files and folders through File transfer Protocol.

We cant Lock resources or cant keep eye onto clients desktop. The proposed System is secured

in a way that we can login to system using Username and Password. With Sharing the files

folder we can also Lock files and folders on clients desktop and also we can lock applications.

Files and application gets encrypted, folder get turned into recycle bin by assigning them

GUID of recycle bin. Thus ,By locking files folder and application we can. keep our data

safe and secured even on clients desktop. With the help of LAN Manager we can also keep

onto clients desktop i.e. we can see what client is doing on his desktop.

2.3 Feasibility study

2.3.1 Economical Feasibility

This study is carried out to check the economic impact that the system will have on the

organization. The amount of fund that the company can pour into the research and devel-

opment of the system is limited. The expenditures must be justified. Thus the developed

system as well within the budget and this was achieved because most of the technologies

used are freely available. Only the customized products had to be purchased.


2.3.2 Operational Feasibility

The aspect of study is to check the level of acceptance of the system by the user. This

includes the process of training the user to use the system efficiently. The user must not feel

threatened by the system, instead must accept it as a necessity. The level of acceptance by

the users solely depends on the methods that are employed to educate the user about the

system and to make him familiar with it. His level of confidence must be raised so that he

is also able to make some constructive criticism, which is welcomed, as he is the final user

of the system.

2.3.3 Technical Feasibility

This study is carried out to check the technical feasibility, that is, the technical requirements

of the system. Any system developed must not have a high demand on the available technical

resources. This will lead to high demands on the available technical resources. This will lead

to high demands being placed on the client. The developed system must have a modest

requirement, as only minimal or null changes are required for implementing this system.

2.4 Risk Analysis

Risk Analysis and management are a series of steps that help a software team to understand

and manage uncertainty. The goal of risk assessment is to prioritize the risks so that attention

and resources can be focused on the more risky items. Risk identification is the first step in

risk assessment, which identifies all the different risks for a particular project. The Problems

or risks that we commonly faced are listed below. Estimation and Scheduling: The unique

nature of individual software projects creates problems for developers in estimating and

scheduling development time. We should refer existing project experience to overcome this

problem. Sudden growth in requirements: There can be a sudden growth in resources that we

have not thought earlier while project planning. This sudden growth can also lead in being

late for project completion. Breakdown of specification: At the initial stage of integration or

coding, we felt that requirements and specifications are incomplete or insufficient. As coding

got progressed, requirement of specification was fulfilled. These risks are project-dependent

and identifying them is an exercise in envisioning what can go wrong. Methods that can aid

risk identification include checklists of possible risks, surveys, meetings and brainstorming,

and reviews of plans, processes, and work products.


Figure 2.2: Gantt chart of LAN Manager

2.5 Project Scheduling

2.6 Effort Allocation

A recommended distribution of effort across the definition and development phases is often

referred to as the 40-20-40 rule. Forty parent of all effort is allocated to front-end analysis

and design. A similar percentage is applied to back-end testing. You can correctly infer that

coding (20 percent of effort) is de-emphasized. This effort distribution should be used as

a guideline only. The characteristics of each project must dictate the distribution of effort.

Work expended on project planning rarely accounts for more than 23 percent of effort, unless

the plan commits an Organization to large expenditures with high risk. Requirements analy-

sis may comprise 10-25 present of project effort. Effort expended on analysis or prototyping

should increase in direct proportion with project size and complexity. A range of 20 to 25

Percent of effort is normally applied to software design. Time expended for design review

and subsequent iteration must also be considered. Because of the effort applied to software

design, code should follow with relatively little difficulty. A range of 15-20 percent of overall

effort can be achieved. Testing and subsequent debugging can account for 30-40 parent of

software development effort.


2.7 Summary

In this chapter, discussion of system analysis has been done. Next chapter will discuss about

System requirement Specification.


Chapter 3

System Requirement Specification

Software requirement engineering is a process of discovery, refinement, modeling, and spec-

ification. Requirement analysis is a software engineering task that bridges gap between

system-level requirements engineering and software design. We identify the requirements of

the users, also the convenience for them, so that they are able to handle our application.

Software Requirements analysis may be divided into five areas of effort:

1. Problem recognition

2. Evaluation and synthesis

3. Modeling

4. Specification

5. Review

3.1 Hardware requirements

1. SYSTEM-PC with P-III or better processor.

2. RAM-Min 196MB of RAM.

3. Hard Disk : 40 GB.

4. Network : Ethernet card ,NIC card,LAN Cables.

3.2 Software requirements

1. Windows Xp/7/8

2. Jdk

3. MySql server


3.3 Functional requirements

1. Login System: To connect in local area network through admin login only.

2. Connection window: This allows server to connect with clients by inserting IP address

of client.

3. Functionality Menu: This allows server to share files, folder or to download files and

folder. It also allows server to lock resources such application, files and folders. Another

use of this menu is to keep eye on clients desktop.

3.4 Non-Functional requirements

If user starts a client program, system would automatically provide ’Login box’ which will

provide username and password for user. Allow failure of log in must not more than three

times. System is enabled of Database coordination which means the register information will

maintained for Pen Drive detection and taken into database system and will be refreshed

after we will fire a query for retrieving the database.

3.5 Summary

In this chapter, discussion about system requirement specification has been done. Next

chapter will discuss about system design.


Chapter 4

System Design

4.1 System Architecture

Figure 4.1: System Architecture

System architecture of the system is nothing but the architecture of the RMI system in

java.

4.1.1 Interfaces: The Heart of RMI

The RMI architecture is based on one important principle: the definition of behavior and

the implementation of that behavior are separate concepts. RMI allows the code that defines

the behavior and the code that implements the behavior to remain separate and to run on


separate JVMs. This fits nicely with the needs of a distributed system where clients are

concerned about the definition of a service and servers are focused on providing the service.

Specifically, in RMI, the definition of a remote service is coded using a Java interface. The

implementation of the remote service is coded in a class. Therefore, the key to understanding

RMI is to remember that interfaces define behavior and classes define implementation. While

the following diagram illustrates this separation,

Figure 4.2: Interface of RMI

Remember that a Java interface does not contain executable code. RMI supports two

classes that implement the same interface. The first class is the implementation of the

behavior, and it runs on the server. The second class acts as a proxy for the remote service

and it runs on the client. This is shown in the following diagram. A client program makes

method calls on the proxy object, RMI sends the request to the remote JVM, and forwards

it to the implementation. Any return values provided by the implementation are sent back

to the proxy and then to the client’s program.

4.1.2 RMI Architecture Layers:

With an understanding of the high-level RMI architecture, take a look under the covers to

see its implementation. The RMI implementation is essentially built from three abstraction

layers. The first is the Stub and Skeleton layer, which lies just beneath the view of the

developer. This layer intercepts method calls made by the client to the interface reference

variable and redirects these calls to a remote RMI service. The next layer is the Remote

Reference Layer. This layer understands how to interpret and manage references made from

clients to the remote service objects. The transport layer is based on TCP/IP connections

between machines in a network. It provides basic connectivity, as well as some firewall

penetration strategies.

By using a layered architecture each of the layers could be enhanced or replaced without

affecting the rest of the system. For example, the transport layer could be replaced by a

UDP/IP layer without affecting the upper layers.


Figure 4.3: fig.4

4.1.3 Stub and Skeleton Layer:

The stub and skeleton layer of RMI lie just beneath the view of the Java developer. In this

layer, RMI uses the Proxy design pattern. In the Proxy pattern, an object in one context is

represented by another (the proxy) in a separate context. The proxy knows how to forward

method calls between the participating objects. The following class diagram illustrates the

Proxy pattern.In RMI’s use of the Proxy pattern, the stub class plays the role of the proxy,

and the remote service implementation class plays the role of the Real Subject. A skeleton is a

helper class that is generated for RMI to use. The skeleton understands how to communicate

with the stub across the RMI link. The skeleton carries on a conversation with the stub; it

reads the parameters for the method call from the link, makes the call to the remote service

implementation object, accepts the return value, and then writes the return value back to

the stub.

4.1.4 Remote Reference Layer:

The Remote Reference Layers defines and supports the invocation semantics of the RMI

connection. This layer provides a RemoteRef object that represents the link to the remote

service implementation object.The stub objects use invoke () method in RemoteRef to for-

ward the method call. The RemoteRef object understands the invocation semantics for

remote services. RMI provides two way for clients to connect to remote service implementa-

tions: First is a unicast, point-to-point connection. Before a client can use a remote service,

the remote service must be instantiated on the server and exported to the RMI system. (If

it is the primary service, it must also be named and registered in the RMI Registry).Second

is an activatable remote object. When a method call is made to the proxy for an activat-

able object, RMI determines if the remote service implementation object is dormant. If it

is dormant, RMI will instantiate the object and restore its state from a disk file. Once an

activatable object is in memory, it behaves just like remote service implementation objects.

Other types of connection semantics are possible. For example, with multicast, a single

proxy could send a method request to multiple implementations simultaneously and accept


Figure 4.4: fig.6

the first reply (this improves response time and possibly improves availability).

4.1.5 Transport Layer:

The Transport Layer makes the connection between JVMs. All connections are stream-

based network connections that use TCP/IP. Even if two JVMs are running on the same

physical computer, they connect through their host computer’s TCP/IP network protocol

stack. (This is why you must have an operational TCP/IP configuration on your computer

to run the Exercises in this course). The following diagram shows the unfettered use of

TCP/IP connections between JVMs.

As you know, TCP/IP provides a persistent, stream-based connection between two ma-

chines based on an IP address and port number at each end. Usually a DNS name is used

instead of an IP address; this means you could talk about a TCP/IP connection between

flicka.magelang.com:3452 and rosa.jguru.com:4432. In the current release of RMI, TCP/IP

connections are used as the foundation for all machine-to-machine connections.

On top of TCP/IP, RMI uses a wire level protocol called Java Remote Method Protocol

(JRMP). JRMP is a proprietary, stream-based protocol that is only partially specified is

now in two versions. The first version was released with the JDK 1.1 version of RMI and

required the use of Skeleton classes on the server. The second version was released with the

Java 2 SDK. It has been optimized for performance and does not require skeleton classes.

The RMI transport layer is designed to make a connection between clients and server,

even in the face of networking obstacles. While the transport layer prefers to use multiple

TCP/IP connections, some network configurations only allow a single TCP/IP connection

between a client and server (some browsers restrict applets to a single network connection

back to their hosting server). In this case, the transport layer multiplexes multiple virtual

connections within a single TCP/IP connection.


4.2 E-R diagram

Figure 4.5: Entity Relationship Diagram

4.3 Data Flow Diagram (up to level-2)

Figure 4.6: Data Flow Diagram:Level 0


4.4 Interface Design

4.4.1 User Interface Design

A graphical user interface is built of graphical elements called components. Typical compo-

nents include such items as buttons, scrollbars, and text fields. Components allow the user

to interact with the program and provide the user with visual feedback about the state of



Figure 4.9: User interface component tree

the program. In the AWT. Inheritance relationship between the user interface component

classes provided by the AWT.

Figure 4.10: fig

Java.awt.event. An action or occurrence, often generated by the user, to which the

program might respondfor example, key presses, button clicks, or mouse movements. Events

do not adhere to this traditional approach because they occur outside of program control.

When an event happens, the application is notified, causing the execution of a piece of code.

In Java, events are generated by objects. An event is represented by a va.util.EventObject

subclass that carries event information. There are subclasses for each kind of event.


Figure 4.11: Event Diagram

4.4.2 Module to Module Interaction (Using Collaboration Dia-gram)

It shows exactly the same information as the sequence diagram. However collaboration

diagram shows this information in a different ways with a different purpose.

Figure 4.12: Collaboration Diagram between Modules

4.5 Uml Diagrams

UML includes a set of graphic notation techniques to create visual models of software-

intensive systems.


4.5.1 Use Case Diagram

The Use Case Model describes the proposed functionality of the new system. A Use Case

represents a discrete unit of interaction between a user (human or machine) and the system.In

this use case diagram their is interaction between Administrator(user) and Server

Figure 4.13: Internal Use Case Diagram for LAN Manager


4.5.2 Class Diagram

It shows the interaction between classes in the system classes can be seen as the blue prints

for object. Classes contain information and behaviour that acts on that information.A class

on a class diagram is created for each type of object in a sequence and collaboration diagram.

Figure 4.14: Class Diagram for LAN Manager

4.5.3 Component Diagram

It shows you a physical view of your model. A component diagram shows you the s/w

component in your system for the relationship between them.

There are two types of component diagram.

1. Executable components

2. Code libraries


Once the component have been created .They are added to the component diagram. Com-

ponent dependencies shows the compile time and run time dependencies between the com-

ponent.

Figure 4.15: Component Diagram for LAN Manager

4.5.4 Deployment Diagram

It is used by the by project manager, architecture and deployment staff to understand the

physical layout of the system and where the various subsystem will inside. It also helps the

staff responsible for deployment to plan these deployment efforts.

Figure 4.16: Component Diagram for LAN Manager


4.5.5 State Diagram

It provides a way to model the various states in which an object can exists while the class

diagram shows a static picture of classes.The state transition diagram shows the behaviour

of an objects.

Figure 4.17: State Diagram for LAN Manager

4.5.6 Sequence Diagram

Sequence diagrams, performed on a per Use Case basis, examine the flow of method call

calls within a system. A sequence diagram is an interaction diagram that emphasizes the

time-ordering of messages.


4.6 Summary


Figure 4.18: Sequence Diagram for LAN Manger


Chapter 5

Implementation

Important phase in system development is the successful implementation of the new system

design. Implementation includes all those activities that take place to convert from the old

system to the new system or newly invented system.

5.1 Implementation details

1. Pen drive detection : This module defines the detection of the pen drive port. When

the external device is added to the client systems, then the server will get a message

from that particular client system with IP address. Then the server knows. This is

used in any lab examinations. If any student will try for copying by using pen drives

then the server knows that client system and will take an action on him.

In this module Client program will ask again and again to window registry about the

drives and store it into database, whereas server program get the status of database

by firing a query. If the registry encountered a new drive or an extra drive , then the

pc will shutdown as soon as new drive encountered.

2. Files lock/Application : In this module First of all the Server program will execute and

server will give the path of file which is on clients desktop and through BufferedInpu-

tReader the client will receive the file and convert it into byte array and then encrypt

it by adding decimal 5 into every byte of the array .

3. Folder lock: First of all the client program will execute and server will give the path

of folder which is on client desktop and server program will replace the guID of that

folder to convert it into recycle bin

4. Upload/download:Using this module we can transfer files between the client and the

server based on the IP address. This module will initialize TCP socket after that

with the help of input stream we will select the file which we want to share and after


converting it into binary array it will be send to client through output stream. The

client will get the binary array though input stream and client will covert that binary

array into file.

5. Spying module:Using this module we can access the desktop of any remote system

by giving the desired systems IP address and port number we can get the desktop of

that system. It is useful for the teacher to monitor the activities of the student of

that organization.The administrator can be able to get the desktop of that particular

system and can warn the employees if they are doing any illegal activities.

In this module client program will take snapshots after certain interval of time and

paste it into robotactionqueue and will transfer it to server after this server program

will get the snapshots from robotactionlistner and the applet window will show the

clients desktop on server screen.

5.2 Implementation environment

1. Platform : java/oo/jvm

2. Language: java

3. Technology used : RMI

4. Backend : mysql sever

5. Frontend : java

5.3 Flow of system development

T1: Communication: Software development process starts with the communication between

customer and developer. According to need of project, gathering of the requirements related

to project are done.

T2: Planning: It includes complete estimation and scheduling.

T3: Modeling: It includes detailed requirement analysis and project design.

Project Work Breakdown structure (Implementation)

It includes coding and testing steps. Design details are implemented using java program-

ming language.

T11:- GUI Design: GUI (Graphical user interface) design is important phase in project

development .It describe how users interact with system. GUI design will implement using


Figure 5.1: Task network for Implementation

java technology. AWT(abstract window toolkit) use for implement graphical user interface.

AWT provide different components like

1. Button

2. listbox

3. checkbox

4. frame

5. container

6. radio button

7. combo box

All this component required for developing graphical user interface design of given system.

To enhance the quality of design swing component use to develop GUI design.

T111: Template Templates are used to create look and feel for the web application.

These are simply downloaded from the web and then changes are made to them according

to the user request. Cascading style sheets are used for formatting page layout, text, fonts

and images on the page. Cascading style sheets allow to position things on page down to

the exact pixel. Also, if a style is declared in the head section of a page, a change to the

style changes the style on the entire page.

T12: Logical Code: Details about the business logic and Core Java


T13: Event Handling:

T131: Validation This module is design for the purpose of to check whether a particular

user is authorized to perform a particular task on the request of the main controller. The

validation methods access the database by firing SQL query to the database.

T14: Database Database is created to store the information of the users. MySql database

is used as database management system. Beans directly interact with the database to retrieve

the information from the database. The whole database is divided into number of tables to

reduce the complexity and to increase the performance.

T141: Database Access A Class directly interact with the database to retrieve the infor-

mation from the database. The whole database is divided into number of tables to reduce

the complexity and to increase the performance.

T16: Integrating Modules In this phase all the s/w modules are collected and integrated

together.

T17: Testing and debugging Testing is carried out to check whether flow of coding is

correct, to check out the errors of required module.

T2: Delivery Final delivery of project will be given along with the necessary documen-

tation.

5.4 Summary

In this chapter, discussion about Implementation has been done. Next chapter will discuss

about System Testing


Chapter 6

System Testing

The purpose of testing is to discover errors. Testing is the process of trying to discover

every conceivable fault or weakness in a work product. It provides a way to check the

functionality of components, sub assemblies, assemblies and/or a finished product It is the

process of exercising software with the intent of ensuring that the Software system meets its

requirements and user expectations and does not fail in an unacceptable manner. There are

various types of test. Each test type addresses a specific testing requirement

6.1 TESTING STRATEGIES:

We are expected to run a number of tests on the system to make sure that we find as many

bugs as possible. There are different types of test that can be used, both tests that look

at the different parts of the code to ensure it works correctly (white box), and tests that

makes sure that the program has the functions that we have defined in the requirements

specification (black box).

6.1.1 White-box tests

The White-box test or structural test is a test that has the focus on the code of the program.

The test is designed by making test cases that covers the statements and branches of the

program. The test cases are made from analyzing the code that implements the software,

and the focus is to ensure that all parts of the program executes correctly.

6.1.2 Black-box tests

The Black-box test, also known as the functional test, focuses on the problems that the

program is supposed to solve. The test cases are planned by writing a series of inputs and

expected outputs. There should be planned test cases where the program are given valid

input, and cases where the input data is not valid, to see what output that will be generated.


The functional test is to be planned to check if the program has the functionalities that are

specified in the project description. The Black-box test is run from the interface that a user

would be using.

6.1.3 Unit Testing

In computer programming, unit testing is a software verification and validation method

in which a programmer tests if individual units of source code are fit for use. A unit is

the smallest testable part of an application. In procedural programming a unit may be an

individual function or procedure. As a part of the white-box testing, unit-test can be made.

Object-oriented software is built on a number of units in the form of classes. A unit test of

an object oriented system will therefore be with test of the classes. Not all classes should

be tested separately, for some it might be better to test them as part of a larger part of

the system. These decisions should be made considering the role that the class has in the

system, and the risk associated with it.

6.1.4 Integration Testing

Integration testing is the phase in software testing in which individual software modules

are combined and tested as a group. It occurs after unit testing and before system testing.

Integration testing takes as its input modules that have been unit tested, groups them in

larger aggregates, applies tests defined in an integration test plan to those aggregates, and

delivers as its output the integrated system ready for system testing.The Integration Testing

mainly Deals with the Construction and the Architecture. It is a systematic technique

for constructing the program structure while conducting tests to uncover errors associated

with interfacing. The top down approach was used in the testing procedure .The modules

were integrated by moving downwards. They were tested using the depth first search. In

the implementation, some of the classes interact with and implement some non primitive

classes, such as interface classes.

6.1.5 Validation Testing

Validation is the process of checking that a product, service, or system meets specifications

and that it fulfills its intended purpose Validation is Quality assurance process of establishing

evidence that provides a high degree of assurance that a product, service, or system accom-

plishes its intended requirements. This often involves acceptance of fitness for purpose with

end users and other product stakeholders. As per the requirement of the Client the Software

that is developed are updated and validated. Validation testing is done to provide final


assurance that software meets all the functional, behavioral, and performance requirements.

This phase of testing also used Black Box testing exclusively.

6.1.6 System Testing

System testing of software or hardware is testing conducted on a complete, integrated system

to evaluate the system’s compliance with its specified requirement. System testing falls

within the scope of black box testing, and as such, should require no knowledge of the inner

design of the code or logic.As a rule, system testing takes, as its input, all of the ”integrated”

software components that have successfully passed integration testing and also the software

system itself integrated with any applicable hardware system. The purpose of integration

testing is to detect any inconsistencies between the software units that are integrated together

or between any of the assemblages and the hardware. After the completion of the software

the whole software is tested as a whole and resolves every queries of the software before

delivering to the client. The system testing verifies that all the elements of the system

work in union with the software developed and the overall system function /performance is

achieved.

6.1.7 Alpha and Beta Testing

It is virtually impossible to foresee how the customer will really use the program. He may

misinterpret some of the instructions or may enter a strange combination of data .As a result

these two tests were conducted.

6.1.8 Black-Box Testing

Black-box testing also called as behavioral testing, focuses on functional requirements of

software. That is, Black box testing enables the software engineer to derive sets of input

conditions that will fully Exercise all functional requirements for a program. Black box

testing attempts to find errors in the following categories:

1. Incorrect or missing function,

2. Interface errors,

3. Errors in data structure or external data base access,

4. Behaviour or performance errors

5. Initialization and termination errors.


1. Performance Testing: covers a broad range of engineering or functional evaluations

where a material, product, system, or person is not specified by detailed material

or component specifications rather, emphasis is on the final measurable performance

characteristics. In the computer industry, software performance testing is used to

determine the speed or effectiveness of a computer, network, software program or

device. Qualitative attributes such as reliability, scalability and inter operability may

also be evaluated. Performance testing is often done in conjunction with stress testing

2. Load testing: is the process of putting demand on a system or device and measuring its

response Load testing generally refers to the practice of modeling the expected usage

of a software program by simulating multiple users accessing the program concurrently.

As such, this testing is most relevant for multi-user systems, often one built using a

client/server model, such as web servers.

3. Stress Testing:In software testing, ”System stress test” refers to tests that put a greater

emphasis on robustness, availability, and error handling under a heavy load, rather

than on what would be considered correct behavior under normal circumstances. In

particular, the goals of such tests may be to ensure the software does not crash in

conditions of insufficient computational resources (such as memory or disk space),

unusually high concurrency, or denial of service attacks

6.2 Test cases and Test Results:

6.3 Summary

In this chapter, discussion about system testing has been done. Next chapter will discuss

about result and analysis.


Figure 6.1: Test and Test Result of the System


Chapter 7

Results and Analysis

7.1 Result

7.1.1 Enter IP address:

Figure 7.1: fig.

7.1.2 Connection successful

7.1.3 Functional Menu

7.1.4 Pen drive detected

7.1.5 Snapshots of client desktop

7.1.6 Path of .exe file to lock application

7.1.7 Application Locked


Figure 7.2: fig.

Figure 7.3: fig.

Figure 7.4: fig.


Figure 7.5: fig.

Figure 7.6: fig.

Figure 7.7: fig.


Chapter 8

Conclusion and Future Scope

8.1 Conclusion

This is to conclude that the project that we undertook was worked upon with a sincere effort.

Most of the requirements have been fulfilled up to the mark and the requirements which have

been remaining, can be completed with a short extension. It is easy to use, since it uses the

GUI provided in the user dialog. User friendly screens are provided. The application is easy

to use and interactive. It has been thoroughly tested and implemented.

8.2 Future Scope

1. Currently the project has been implemented on Local Area networks and PCs which

are closed coupled in a network.

2. We can increase the functionality in terms of actions that we can perform from a server

on a client.

3. We can use encryption and decryption techniques while sending files and information

from 1 PC to another in a network.

4. We can make all the Login information on server requiring the clients to connect and

access the information to authenticate.


Bibliography

[1] Bone, Mike, Wayman, Dr. James L., and Blackburn, Duane. Evaluating FacialRecog-

nition Technology for Drug Control Applications. ONDCP International Counter-

drug Technology Symposium: Facial Recognition Vendor Test. Department of Defense

Counterdrug Technology Development Program Office, June 2001.

[2] Gross, Ralph, Shi, Jianbo, and Cohn, Jeffrey F. Quo vadis Face Recognition. Third-

Workshop on Empirical Evaluation Methods in Computer Vision. Kauai: December

2001.

[3] Penev, Penio S., and Atick, Joseph J. Local Feature Analysis: A General Statisti-

calTheory for Object Representation. Network: Computation in Neural Systems, Vol.

7, No. 3, pp. 477-500, 1996.

[4] Wrolstad, Jay. NCR To Deploy New Microsoft OS in ATMs. CRMDailyDotCom.

29Nov. 2001.

[5] All, Anne. Triple DES dare you. ATM Marketplace.com. 19 Apr. 2002.


project Report on LAN Security Manager

Education

Transcript of project Report on LAN Security Manager