project Report on LAN Security Manager

A
Minor Project Report
on
LOCAL AREA NETWORK MANAGER
Submitted in Partial Fulﬁllment 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 fulﬁllment 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 eﬀorts 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 ﬁle 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 eﬃciency 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, conﬂicts 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 Speciﬁcation.

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 deﬁnition of behavior and
the implementation of that behavior are separate concepts. RMI allows the code that deﬁnes
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 ﬁelds. 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: ﬁg
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 notiﬁed, 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 diﬀerent ways with a diﬀerent 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 ﬂow 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 ﬁle.
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 diﬀerent 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 ﬁring 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 ﬂow 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: ﬁg.
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 ﬁle 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 Oﬃce, June 2001.
[2] Gross, Ralph, Shi, Jianbo, and Cohn, Jeﬀrey 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

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (20)

Similar to project Report on LAN Security Manager

Similar to project Report on LAN Security Manager (20)

Recently uploaded

Recently uploaded (20)

project Report on LAN Security Manager