Anda di halaman 1dari 57

Mobile Based Lan Monitoring And Control

Today, the world is rapidly changing the statement We are in the world to World is in our hands. The main aim of our project is to control and monitor the LAN network from our wireless handheld device i.e. cell phone from anywhere irrespective of distance. Say, you have a LAN setup at your office. Sitting at home you want to learn the LAN status. You can do so by storing this project in your cell phone and executing the same. In the era of mobile devices, wireless devices are widely used and it has penetrated every part of our life, but remote monitoring of networks through mobile device is still a mirage, this project is an effort to make this mirage a reality, and this is where the genesis of this of this project lies.

1.1 . Problem Statement : LAN monitoring using GSM technology can be used in offices, malls as well as college or university level. The main objective of this project is to provide maximum details about the network to the administrator on their mobile phone, when administrator is away from office / goes out station.

1.2 Literature Survey :

1.2.1 Introduction :
A literature survey is a discussion of the literature in a given area of the study. It is concise overview of what has been studied, argued and established about a topic, and it is usually organized chronologically or thematically. It is not an annotated bibliography, because it groups related works together and discusses trends and developments rather than focusing on one item at a time. It is not a summary, rather it evaluates previous and current research in regard to how relevant and or useful it is.

Mobile Based Lan Monitoring And Control

1.2.2 Technology Information: Servlets The Java Servlet API allows a software developer to add dynamic content to a Web server using the Java platform. The generated content is commonly HTML, but may be other data such as XML. Servlets with JavaServer Pages are the Java counterpart to dynamic web content technologies such as CGI/PHP or ASP.NET/VBScript,JScript,C Sharp. Servlets can maintain state across many server transactions by using HTTP cookies, session variables or URL rewriting. The Servlet API, contained in the Java package hierarchy javax.servlet, defines the expected interactions of a web container and a servlet. A web container is essentially the component of a web server that interacts with the servlets. The web container is responsible for managing the lifecycle of servlets, mapping a URL to a particular servlet and ensuring that the URL requester has the correct access rights. A Servlet is an object that receives requests (ServletRequest) and generates a response (ServletResponse) based on the request. The API package javax.servlet.http defines HTTP subclasses of the generic servlet (HttpServlet) request (HttpServletRequest) and response (HttpServletResponse) as well as an (HttpSession) that tracks multiple requests and responses between the web server and a client. Servlets may be packaged in a WAR file as a Web application. Moreover, servlets can be generated automatically by JavaServer Pages (JSP), or alternately by template engines such as WebMacro. Often servlets are used in conjunction with JSPs in a pattern called "Model 2", which is a flavor of the model-view-controller pattern. J2SE SDK Java Platform, Standard Edition or Java SE (formerly known up to version 5.0 as Java 2 Platform, Standard Edition or J2SE), is a collection of Java programming language APIs useful to many Java platform programs. The Java Platform, Enterprise Edition includes all of the classes in the Java SE, plus a number which are more useful to programs running on servers than on workstations.

Mobile Based Lan Monitoring And Control Starting with the J2SE 1.4 version (Merlin), the Java SE platform has been developed under the Java Community Process. JSR 59 was the umbrella specification for J2SE 1.4 and JSR 176 specified J2SE 5.0 (Tiger). As of 2006, Java SE 6 (Mustang) is being developed under JSR 270. The following are descriptions of some of the primary Java SE packages. For a complete list of packages see the J2SE 5.0 API Javadocs. NetBeans NetBeans refers to both a platform for the development of Java desktop applications, and an integrated development environment (IDE) developed using the NetBeans Platform. The NetBeans Platform allows applications to be developed from a set of modular software components called modules. A module is a Java archive file that contains Java classes written to interact with the NetBeans Open APIs and a manifest file that identifies it as a module. Applications built on modules can be extended by adding new modules. Since modules can be developed independently, applications based on the NetBeans platform can be easily and powerfully extended by third party developers. The NetBeans Platform: The NetBeans Platform is a reusable framework for simplifying the development of other desktop applications. When an application based on the NetBeans Platform is run, the platform's Main class is executed. Available modules are located, placed in an in-memory registry, and the modules' startup tasks are executed. Generally, a module's code is loaded into memory only as it is needed. Applications can install modules dynamically. Any application can include the Update Center module to allow users of the application to download digitally-signed upgrades and new features directly into the running application. Reinstalling an upgrade or a new release does not force users to download the entire application again. The platform offers services common to desktop applications, allowing developers to focus on the logic specific to their application. Among the features of the platform are: User interface management (e.g. menus and toolbars) User settings management

Mobile Based Lan Monitoring And Control Storage management (saving and loading any kind of data) Window management Wizard framework (supports step-by-step dialogs) The NetBeans IDE is an open-source integrated development environment written entirely in Java using the NetBeans Platform. NetBeans IDE supports development of all Java application types (J2SE, web, EJB and mobile applications) out of the box. Among other features are an Ant-based project system, version control and refactoring. The current version is NetBeans IDE 5.5.1, which was released in May 2007. NetBeans IDE 5.5 extends the existing Java EE features (including Java Persistence support, EJB 3 and JAX-WS). Additionally, the NetBeans Enterprise Pack supports development of Java EE 5 enterprise applications, including SOA visual design tools, XML schema tools, web services orchestration (for BPEL), and UML modeling. The NetBeans C/C++ Pack supports C/C++ projects. NetBeans 5.5.1 builds on the functionality of NetBeans 5.5 and also provides several bug fixes. NetBeans IDE 5.5 builds upon the previous version 5.0, which introduced comprehensive support for developing IDE modules and rich client applications based on the NetBeans platform, a new GUI builder (formerly known as "Project Matisse"), new and redesigned CVS support, Weblogic 9 and JBoss 4 support, and many editor enhancements. Modularity: All the functions of the IDE are provided by modules. Each module provides a well defined function, such as support for the Java language, editing, or support for the CVS versioning system. NetBeans contains all the modules needed for Java development in a single download, allowing the user to start working immediately. Modules also allow NetBeans to be extended. New features, such as support for other programming languages, can be added by installing additional modules. For instance, Sun Studio, Sun Java Studio Enterprise, and Sun Java Studio Creator from Sun Microsystems are all based on the NetBeans IDE.

Mobile Based Lan Monitoring And Control Process Builder This class is used to create operating system processes. Each ProcessBuilder instance manages a collection of process attributes. The start() method creates a new Process instance with those attributes. The start() method can be invoked repeatedly from the same instance to create new subprocesses with identical or related attributes. Each process builder manages these process attributes: A command, a list of strings which signifies the external program file to be invoked and its arguments, if any. Which string lists represent a valid operating system command is system-dependent. For example, it is common for each conceptual argument to be an element in this list, but there are operating systems where programs are expected to tokenize command line strings themselves - on such a system a Java implementation might require commands to contain exactly two elements. An environment, which is a system-dependent mapping from variables to values. The initial value is a copy of the environment of the current process. A working directory. The default value is the current working directory of the current process, usually the directory named by the system property user.dir. A redirectErrorStream property. Initially, this property is false, meaning that the standard output and error output of a subprocess are sent to two separate streams, which can be accessed using the Process.getInputStream() and Process.getErrorStream() methods. If the value is set to true, the standard error is merged with the standard output. This makes it easier to correlate error messages with the corresponding output. In this case, the merged data can be read from the stream returned by Process.getInputStream(), while reading from the stream returned by Process.getErrorStream() will get an immediate end of file. Modifying a process builder's attributes will affect processes subsequently started by that object's start() method, but will never affect previously started processes or the Java process itself. Most error checking is performed by the start() method. It is possible to modify the state of an object so that start() will fail. For example, setting the command attribute to an empty list will not throw an exception unless start() is invoked.

Mobile Based Lan Monitoring And Control Note that this class is not synchronized. If multiple threads access a ProcessBuilder instance concurrently, and at least one of the threads modifies one of the attributes structurally, it must be synchronized externally. Tomcat Apache Apache Tomcat (formerly under the Apache Jakarta Project; Tomcat is now a top level project) is a web container developed at the Apache Software Foundation. Tomcat implements the servlet and the JavaServer Pages (JSP) specifications from Sun Microsystems, providing an environment for Java code to run in cooperation with a web server. It adds tools for configuration and management but can also be configured by editing configuration files that are normally XML-formatted. Tomcat includes its own HTTP server internally. Environment: Tomcat is a web server that supports servlets and JSPs. Tomcat comes with the Jasper compiler that compiles JSPs into servlets. The Tomcat servlet engine is often used in combination with an Apache webserver or other web servers. Tomcat can also function as an independent web server. Earlier in its development, the perception existed that standalone Tomcat was only suitable for development environments and other environments with minimal requirements for speed and transaction handling. However, that perception no longer exists; Tomcat is increasingly used as a standalone web server in high-traffic, high-availability environments. Since its developers wrote Tomcat in Java, it runs on any operating system that has a JVM. Abstract Window Toolkit The Abstract Window Toolkit (AWT) is Java's original platform-independent windowing, graphics, and user-interface widget toolkit. The AWT is now part of the Java Foundation Classes (JFC) the standard API for providing a graphical user interface (GUI) for a Java program.

Mobile Based Lan Monitoring And Control AWT is also the GUI toolkit for a number of Mobile Java profiles. For example, Connected Device Configuration profiles require Java runtimes on mobile telephones to support AWT. The AWT provides two levels of APIs:

A general interface between Java and the native system, used for windowing, events, layout managers. This API is at the core of Java GUI programming and is also used by Swing and Java 2D. It contains:
o o o o o

The interface between the native windowing system and the Java application The core of the GUI event subsystem, Several layout managers, The interface to input devices such as mouse and keyboard, A java.awt.datatransfer package for use with the Clipboard and Drag and Drop,

A basic set of GUI widgets such as buttons, text boxes, and menus. it also provide the AWT Native Interface, which enables rendering libraries compiled to native code to draw directly to an AWT Canvas object drawing surface.

AWT also provide some miscellaneous useful utilities, that can also be used by Swing, such as:

Access to the system tray on supporting systems, The ability to launch some desktop applications such as web browsers and email clients from a Java application. Neither AWT nor Swing are inherently thread safe. Therefore, code that updates the

GUI or processes events should execute on the Event dispatching thread. Failure to do so may result in a deadlock or race condition. To address this problem, a utility class called SwingWorker allows applications to perform time-consuming tasks following userinteraction events in the event dispatching thread. Implementation: As AWT bridge to the underlying native user interface, its implementation on a new operating system may involve a lot of work, especially for the set of AWT GUI widgets, which require to develop ab initio a native peer for each of AWT widgets.Since the opening

Mobile Based Lan Monitoring And Control of Java, a project called Caciocavallo has been created. It aims to provide a Java API based on OpenJDK to ease AWT implementation on a new system. The project has successfully experimented the implementation of AWT widgets using Java2D. 1.3 Brief Idea 1.3.1 Features controlled by cell phone Net View: Get in your cell phone, the list of entire clients in LAN. Keep pinging every time to check the latest status of the PCs. Anytime, the PC goes offline, its name is removed from the list. Process List: Get the list of all the processes running in the remote machine. Activate Process: Activate different processes in either the server machine or any of the clients. Kill Process: Kill the desired processes in either the server or clients. Read: You can read the drives, folders, files of any of the client machines/ the server machine from cell. Open File: A small text file residing in any of the client or the server machine can be opened in your cell phone. Broadcast messages: Broadcast messages to clients, Server from cell. New File: Create a new document in the cell phone and save the same in either the server or client machine. Shut Down the client machines from mobile

Mobile Based Lan Monitoring And Control


This is software requirement specification for SMS. The purpose of this subject is to convey information about applications requirements, both functional and non functional to the reader a)this document provides the description of the environment in which the application is expected to operate, b)a definition of application capabilities and c)the specification of the applications functional and non functional requirements Its serves the following group of audiences : 1. It helps the application designer with the clear view of the project requirement s Designers will use this information recorded here as the basis for creating the applications design 2. It helps the ultimate user that is the network administrator to cause the full capability of the application 3. It will be used for test planning and designing the test cases

2.2 Scope :
Software scope is the first software project management activity it describes the data and control the processed, function, performance, constraints, interfaces and reliability. Function described in the statement of scope are evaluated and in some cases refined to provide more details prior to beginning of estimation because both cost and schedule estimates are functionally oriented, some degree of decomposition is often useful constraint identify the limit placed on the software by external hardware, available memory or other existing systems . performance considerations in encompass processing and response time requirements. 2.2 Overall Description : Mobile based lan monitoring and control is a tool used to monitor a lan through a mobile device by the administrator when he is at a remote site.

Mobile Based Lan Monitoring And Control This tool is installed on the node which has two independent parts. One is server application which works as a major process on the machine and offer the services to administrator for controlling and monitoring the lan. The other is the client application which is the background process on the machine and control all the activities of the client and gives feedback to the server. The server application can control through registered mobile device. Using that mobile device the administrator can perform following actions 1)kill process 2)start process 3)open file 4)delete file 5)broadcast message The client application retrieves the list of processes running on the machine and send it back to the server application. The server keep the list updated to check for live hosts. The server can contact to the particular client using his id.

2.4 Architecture :
Administrator sends his request through SMS using his mobile phone having MIDP 1.0 tech on his phone via GSM modem to the server. Server then recognizes the client machine which administrator is supposed to monitor and extract data from locally cached data buffer where latest 15 sec data of every machine is updated or stored and sends this info to the administrator as response. Administrator is provided with a GUI based application in J2ME to send command message instantly without the need to retype message every time. Server sends command to the clients like start process, shutdown process, kill process, create, delete, send task list, compile code Through the GSM service provider the communication is done with the GSM modem which communicates with the server and the server communicates with the client. All clients are controlled and monitored by administrator via a series of SMS text messages for which we are using a SMS parser to parse the SMS . The administrator controls the LAN through his mobile even he is at the remote place. The clients cannot send back or communicate to the administrator the communication is unidirectional it is not two way. Only the administrator can give command to the clients. The mobile used can be any mobile which has a GSM facility in it. Also the administrator can check the network load on the LAN by typing only a command. In this also a serial USB interface and a set of commands is used for the administrator to communicate to

Mobile Based Lan Monitoring And Control the clients. The block diagram above shows how the operation takes place of the entire system. 2.5 Block Diagram


Mobile Based Lan Monitoring And Control

2.6 Modules : Server GUI: Server side GUI to be designed in NetBeans 6.0 using Java Swing Technology. Contains GUI for communication with client. Client GUI: Client side GUI to be designed in NetBeans 6.0 using Java Swing Technology. Command can be given to the clients. Data Library: Database design to be created using Java Object Serialization (Java Class Library creation in NetBeans). Database containing client status. GSM Modem Interfacing: Modem interfacing at Server using Nokia PC Connectivity SDK (This module is created in VB) To interface GSM Modem with the server. JAVA-VB interface: This is a minor module used to interface the last mentioned VB module so that messages (SMS) can be sent/received from within Java. Servlets: Several java servlets need to be written in order to achieve client server communication. Server: We need to configure Tomcat Apache 5.5 server in order to get the

Mobile Based Lan Monitoring And Control servlets running. Servlets used for communication between client and the server. OS Interfacing: Several modules need to be programmed in order to access the tasks currently running on any client. Mobile Module (Optional): A GUI module for mobile can be programmed which would ease the process of typing and sending monitor and control messages from administrator mobile. Log: A module to maintain log of all the activities on server. SMS Parser: A module to parse messages being sent by administrator. Authentication: A Client Side Monitor: A client module that continuously checks the current tasks on that client and reports it to server. It also listens to any request received from server. Server Control: A module to control and monitor all the clients form server directly. SMS Control: Finally the module to control and monitor all the clients from administrator mobile. module to authenticate administrator via his/her number/password.


Mobile Based Lan Monitoring And Control

2.7 User Characteristics

One type of users for the System are
Administrator sitting on the server machine. Administrator using cell phone

Type of user

User Characteristic

User technical expertise

User sitting on the client machine

User using cell phone

1)has some knowledge of pc depending on the work he/she is associated with 2)will not have any formal training to use the system 1)has some knowledge of different commands that can be send through cell phone

1)has some exposure to windows environment 2)need not have knowledge of hardware and networking 1) need not have any technical knowledge

How the user characteristic and technical expertise affect project functionalities 1) GUI may be easier to learn 2)provides appropriate error messages for invalid user inputs 1)commands should be easy to remember according to their functionality


Mobile Based Lan Monitoring And Control

2.8 Schedule : Software scheduling is a activity that distributes estimated efforts across the planned project duration by allocating the effort to specific software engineering tasks. Like all other areas of software engineering, number of basic principles guide software project scheduling. Interdependency : Some tasks must occurs in sequence while others can occurs in parallel. Some activities cant commence until the work product produced by another is available. Time Allocation : Each task to be scheduled must be allocated some number of work units (for example person days of effort). Effort Validation : Every project has a defined number of staff members and project manager should allocate the number of people that are scheduled at any given time for a particular task. Defined Responsibilities : Every task that is scheduled should be assigned to a specific team member. Defined Outcomes : Every task that is scheduled should have defined outcome, normally a work product. Word products are often combined in deliverables.


Mobile Based Lan Monitoring And Control

Defined Milestones : Every task or group of tasks should be associated with project milestones. A milestone is accomplished when one or more work products has been reviewed for quality and has been approved. Each of this principle is applied as the project schedule evolves. Tasks Performed Selecting the field of interest Searched companies interested in sponsoring B.E Understanding the problem statement and the company requirement Collected information about the topic Prepared the abstract and decide the modules Prepared detailed synopsis and seminar related information

Number Of Days Required 6 15

Start Date 6/07/2009 13/7/2009

End Date 12/7/2009 3/8/2009









Mobile Based Lan Monitoring And Control Prepared for seminar presentation Decided to build a s/w engg. Model of the project Submission of preliminary report Studied Java Concepts Designing for Graphical User Interface Coding for modules prepared Software design specification Report Generation 1 month 4 20 5/02/2010 5/03/2010 9/03/2010 4/3/2010 8/03/2010 30/03/2010 8 1 month 15 14/10/2009 15/12/2009 18/1/2010 22/10/2009 15/1/2010 2/02/2010 14 7 31/8/2009 21/9/2009 7/09/2009 5/10/2009


Mobile Based Lan Monitoring And Control

2.9 SQA Plan

Introduction Software quality assurance is an umbrella activity that is applied is at each step in the software process. SQA encompasses procedures for effective application of methods and tools, formal technical reviews, testing strategies and techniques, procedures for change control, procedures for assuring compliance to standards and measurement and reporting mechanism. Purpose of Plan The SQA plan provides a road map for instituting software quality assurance. The plan serves as template for SQA activities that are instituted for each software project. Management Management section of the plan describes SQAs place in the organizational structure, SQA tasks and activities and their placement through out the software process and the organizational roles and responsibilities relative to product quality.

2.10 Feasibility
The feasibility study involved in the conception of the project requires a study of the environment as well as the risks involved in the development of the project. Proper estimation has to be carried out to ensure timely delivery of components as well as the cost effective solutions.

Technical Feasibility The work for the project can be done with presently available equipment current procedures, existing technology and available manpower . No new technology needs to be introduced hence system is technically feasible. We are going to use programming language

Mobile Based Lan Monitoring And Control JAVA for this product development hence we can say that technically the project is platform independent. Financial feasibility The minimum hardware and software equipment required for running the system is already available. The only cost incurred is that of developing and maintenance of the system. Hence system is cost effective and economically feasible. Operational feasibility The system is designed keeping in mind the user requirements and can be implemented with existing personnel. Implementing the system is not a major concern as system is user friendly and easy to work. Cost Feasibility The costing feasibility of the project can be estimated using current estimation models such as lines of code, which allows us to estimate cost as a function of size. Thus, this also allows us to estimate and analyze the feasibility of competition of the system in the given time frame. This allows us to have a realistic estimate as well as a continuous evaluative perspective of the progress of the project.


Mobile Based Lan Monitoring And Control



Design Considerations :
Assumptions and Dependencies In order to write a code using JAVA we need to install Netbeans-6.7.1and JDK1.6.

Related Software and hardware We use NetBeans refers to both a platform for the development of Java desktop applications, and an integrated development environment (IDE) . Operating system With minor allowances for the peculiarities of particular operating systems, the application can be modified to act largely platform independent since it has been written in JAVA. The application has however been developed using Windows XP and will naturally work without changes on the operating systems. End user characteristics The end user of system will be employees of a any organization or colleges. So the system has been developed keeping in mind certain assumptions regarding knowledge of LAN based system . The system can be deployed in company or colleges having a LAN administration.

3.1.2 General constraints

The project operates under a number of design and implementation constraints.Some of these are as outlined below: Hardware and Software constraints


Mobile Based Lan Monitoring And Control Since the project has been developed entirely using JAVA and object oriented methodology, it is largely independent. The project can be run on any platform. However, it still needs a JAVA framework to run (Net Beans). End user constraints As mentioned above the major constraints for the end user is having a Java framework on his computer.Also he should be familiar with the the operation with the system to a certain extent,although a help document will be provided to oriented users. Design Methodology The design is a primarily top down approach, identifying all the distinct modules in the system and the interfaces between them and then moving down into each module to design the increasingly more detailed aspects such as the beans and classes being used for implementation. Database and Repository requirements We intend to use a temporary database for the storage of data like file system. Network connection As the name suggest the project is nothing but LAN. It is the most important thing in the project.


JAVA Language
When the chronicle of computer languages is written, the following will be said: B led to

C, C evolved into C++, and C++ set the stage for Java. To understand Java is to understand the reasons that drove its creation, the forces that shaped it, and the legacy that it inherits. Like the successful computer languages that came before, Java is a blend of the best elements of its rich heritage combined with the innovative concepts required by its unique environment. The key considerations were summed up by the Java team in the following list of buzzwords: Simple

Mobile Based Lan Monitoring And Control Secure Portable Object-oriented Robust Multithreaded Architecture-neutral Interpreted High performance Distributed Dynamic


Design Strategy

User Assistance Following provisions are made for assisting the user Reporting : Error reporting performed through pop-up responses. User docs: Documents for users through User manuals.

Error Handling Reporting Following error handling will be provided: User input validation Return values of the file operations and other functions.

Scalability Following care is taken to improve scalability: Worst case size of lists is considered. Loops in the code are scrutinized for worst-case iterations.

Security Some security measures are implemented such as authorization of mobile user.


Mobile Based Lan Monitoring And Control Migration If we are updating existing software, we will make it as easy as possible for end users to migrate from previous versions to new versions by considering following things: Using same names for applications, parameters and menu commands as that in previous one. Using the same configurable variables as in previous version. Using the same parameter units as in previous version.

3.4 UML Diagrams



Mobile Based Lan Monitoring And Control

3.4.1 Use Case Diagram

Figure: 3.4.1

Section Description

Purpose When a person registers as an authenticated and valid user then he is empowered with some operations which he uses according to his

Mobile Based Lan Monitoring And Control needs and convenience. Administrator and Mobile User User must be one who has already being enrolled.

Actors Preconditions

3.1 Class Diagram


Mobile Based Lan Monitoring And Control

3.4.3 Sequence Diagram


Mobile Based Lan Monitoring And Control

3.4.4 Activity Diagram


Mobile Based Lan Monitoring And Control

3.4.5 Collaboration Diagram


Mobile Based Lan Monitoring And Control

3.4.6 Component Diagram


Mobile Based Lan Monitoring And Control

3.4.7 Package Diagram


Mobile Based Lan Monitoring And Control

3.4.8 Deployment Diagram


Mobile Based Lan Monitoring And Control



Mobile Based Lan Monitoring And Control


LAN PCs (At least two) Network Cards GSM Modem


J2SE JDK 1.6 NetBeans 6.7.1 Tomcat Apache Server 6.0 Nokia PC Connectivity SDK

4.3 Coding
//Server Side Coding class MonitorTimerTask extends TimerTask { public Server parent; int progress; public MonitorTimerTask(Server parent) { this.parent = parent; progress = 0; } public void run() { if(!parent.runningMonitor) { return; }

Mobile Based Lan Monitoring And Control

progress++; if(progress == 6) { progress = 0; } parent.jLabelProcess.setIcon(new ImageIcon(System.getProperty("user.dir") + "\\src\\zImgPack\\" + progress + ".png")); if(progress>0) { return; } // see if some clients are offline more than 5 seconds... if(parent.jCheckAutoRemove.isSelected()) { for(int i=0;i<parent.clientDB.size();i++) { long timeNow = Calendar.getInstance().getTimeInMillis(); long timeThen = parent.clientDB.get(i).refreshTime.getTimeInMillis(); if(((timeNow - timeThen)/1000) > 5) { parent.clientDB.remove(i); i--; } } parent.updateClients(); parent.updateProcesses(); } // monitor any client information File fromClientDir = new File(System.getProperty("user.dir") + "\\FROM CLIENTS"); File clientRequests[] = fromClientDir.listFiles(); for(int i=0;i<clientRequests.length;i++) { try { // read object

Mobile Based Lan Monitoring And Control ObjectInputStream in1 = new ObjectInputStream(new FileInputStream(clientRequests[i])); ClientInfo ci = (ClientInfo)in1.readObject(); in1.close(); // process info parent.processClient(ci); // delete file after using clientRequests[i].delete(); }catch(Exception e) { System.out.println("Exception: " + e); } } // monitor sms File smsFile = new File(System.getProperty("user.dir") + "\\autoSMS\\out\\last.txt"); if(smsFile.exists()) { try { BufferedReader br = new BufferedReader(new FileReader(smsFile)); String msg, temp; msg = ""; while((temp = br.readLine())!=null) { msg += temp; } br.close(); new File("" + System.getProperty("user.dir") + "\\autoSMS\\out\\last.txt").delete(); parent.addText("SMS RECEIVED!",true); StringTokenizer st = new StringTokenizer(msg,"$$"); Vector <String> msgBroken = new Vector <String> (); while(st.hasMoreElements()) {

Mobile Based Lan Monitoring And Control msgBroken.add(st.nextToken()); } // verify sender if(msgBroken.get(0).contains( { StringTokenizer st2 = new StringTokenizer(msgBroken.get(1),"##"); Vector <String> smsCommand = new Vector <String> (); while(st2.hasMoreElements()) { smsCommand.add(st2.nextToken()); } if(smsCommand.size()==0) { parent.addText("INVALID MESSAGE FORMAT!",false); return; } if(smsCommand.get(0).equals( { parent.addText("Sender Verified!",false); smsCommand.remove(0); }else { parent.addText("SMS Authentication Failed!",false); return; } if(smsCommand.get(0).equals("LISTALL") && smsCommand.size()==1) { String msgResponse = ""; parent.addText("CMD: LIST CLIENTS.",false); msgResponse += "CLIENTS: "; for(int i=0;i<parent.clientDB.size();i++) { msgResponse += parent.clientDB.get(i).name; }

Mobile Based Lan Monitoring And Control sendToAdmin(msgResponse); }else if(smsCommand.get(0).equals("SD") && smsCommand.size()==2) { parent.addText("CMD: SHUTDOWN CLIENT (" + smsCommand.get(1) + ").",false); ClientCommand cc = new ClientCommand(); cc.clientName = smsCommand.get(1); cc.command = 1; parent.clientCommandDB.add(cc); }else if(smsCommand.get(0).equals("STARTP") && smsCommand.size()==3) { parent.addText("CMD: START PROCESS (" + smsCommand.get(2) + ") FOR " + smsCommand.get(1) + ".",false); ClientCommand cc = new ClientCommand(); cc.clientName = smsCommand.get(1); cc.command = 2; cc.parameters.add(smsCommand.get(2)); parent.clientCommandDB.add(cc); }else if(smsCommand.get(0).equals("KILL") && smsCommand.size()==3) { parent.addText("CMD: KILL (" + smsCommand.get(2) + ") FOR " + smsCommand.get(1),false); ClientCommand cc = new ClientCommand(); cc.clientName = smsCommand.get(1); cc.command = 3; if(!smsCommand.get(2).toUpperCase().endsWith(".EXE")) { cc.parameters.add(smsCommand.get(2) + ".EXE"); }else { cc.parameters.add(smsCommand.get(2)); } parent.clientCommandDB.add(cc); }else if(smsCommand.get(0).equals("NEW") && smsCommand.size()==4) {

Mobile Based Lan Monitoring And Control parent.addText("CMD: CREATE FILE (" + smsCommand.get(2) + ") FOR " + smsCommand.get(1),false); ClientCommand cc = new ClientCommand(); cc.clientName = smsCommand.get(1); cc.command = 4; cc.parameters.add(smsCommand.get(2)); cc.parameters.add(smsCommand.get(3)); parent.clientCommandDB.add(cc); }else if(smsCommand.get(0).equals("DEL") && smsCommand.size()==3) { parent.addText("CMD: DELETE FILE (" + smsCommand.get(2) + ") FOR " + smsCommand.get(1),false); ClientCommand cc = new ClientCommand(); cc.clientName = smsCommand.get(1); cc.command = 5; cc.parameters.add(smsCommand.get(2)); parent.clientCommandDB.add(cc); }else if(smsCommand.get(0).equals("READ") && smsCommand.size()==3) { parent.addText("CMD: READ FILE (" + smsCommand.get(2) + ") FOR " + smsCommand.get(1),false); ClientCommand cc = new ClientCommand(); cc.clientName = smsCommand.get(1); cc.command = 6; cc.parameters.add(smsCommand.get(2)); parent.clientCommandDB.add(cc); }else if(smsCommand.get(0).equals("LIST") && smsCommand.size()==3) { parent.addText("CMD: LIST FILES (" + smsCommand.get(2) + ") FOR " + smsCommand.get(1),false); ClientCommand cc = new ClientCommand(); cc.clientName = smsCommand.get(1); cc.command = 8; cc.parameters.add(smsCommand.get(2));

Mobile Based Lan Monitoring And Control parent.clientCommandDB.add(cc); }else if(smsCommand.get(0).equals("MSG") && smsCommand.size()==3) { parent.addText("CMD: MESSAGE FOR (" + smsCommand.get(1) + ")",false); ClientCommand cc = new ClientCommand(); cc.clientName = smsCommand.get(1); cc.command = 7; cc.parameters.add(smsCommand.get(2)); parent.clientCommandDB.add(cc); }else if(smsCommand.get(0).equals("MSGB") && smsCommand.size()==2) { parent.addText("CMD: MESSAGE BROADCAST.",false); for(int i=0;i<parent.clientDB.size();i++) { ClientCommand cc = new ClientCommand(); cc.clientName = parent.clientDB.get(i).name; cc.command = 7; // message cc.parameters.add(smsCommand.get(1)); parent.clientCommandDB.add(cc); } }else if(smsCommand.get(0).equals("COMP") && smsCommand.size()==2) { parent.addText("CMD: CODE COMPILE.",false); for(int i=0;i<parent.clientDB.size();i++) { ClientCommand cc = new ClientCommand(); cc.clientName = parent.clientDB.get(i).name; cc.command = 7; // message cc.parameters.add(smsCommand.get(1)); parent.clientCommandDB.add(cc); } }else { parent.addText("INVALID MESSAGE FORMAT!",false); sendToAdmin("INVALID MESSAGE FORMAT!"); }

Mobile Based Lan Monitoring And Control

}else{ parent.addText("SENDER NOT AUTHORISED!",false); } br.close(); }catch(Exception e) { System.out.println("Error Interpreting Message Text: " + e); } } }

4.4 ScreenShots

Mobile Based Lan Monitoring And Control


Servlet is first program to run on the Server side Servlet is used for communication purpose between Server and Client

Server Main Form


Mobile Based Lan Monitoring And Control

This is main menu provided to the Administrator at Server side This is used for handling various activities for Administrator at Server Side.

Server Form

Mobile Based Lan Monitoring And Control

This is main form provided to Administrator at Server Side. Administrator can perform various functions on active Clients such as start new process, shut down client, create file on client machine etc.

Client Form

Mobile Based Lan Monitoring And Control

This is GUI provided for Client to view the different activities performed by Administrator on itself. Also used to see the messages sent from Administrator.


Mobile Based Lan Monitoring And Control


5.1 Testing : Software Testing is an empirical investigation conducted to provide stakeholders with information about the quality of the product or service under test, with respect to the context in which it is intended to operate. This includes, but is not limited to, the process of executing a program or application with the intent of finding software bugs. Testing can never completely establish the correctness of computer software. Instead, it furnishes a criticism or comparison that compares the state and behaviour of the product against oraclesprinciples or mechanisms by which someone might recognize a problem. These oracles may include (but are not limited to) specifications, comparable products, past versions of the same product, inferences about intended or expected purpose, user or customer expectations, relevant standards, applicable laws, or other criteria. Over its existence, computer software has continued to grow in complexity and size. Every software product has a target audience. For example, the audience for video game software is completely different from banking software. Therefore, when an organization develops or otherwise invests in a software product, it presumably must assess whether the software product will be acceptable to its end users, its target audience, its purchasers, and other stakeholders. Software testing is the process of attempting to make this assessment.


Static vs. dynamic testing

There are many approaches to software testing. Reviews, walkthroughs or inspections are considered as static testing, whereas actually executing programmed code with a given set of test cases is referred to as dynamic testing. The former can be, and unfortunately in practice often is, omitted, whereas the latter takes place when programs begin to be used for the first time - which is normally considered the beginning of the testing stage. This may actually begin before the program is 100% complete in order to test particular sections of code (modules or discrete functions). For example, Spreadsheet programs are, by their very nature, tested to a large extent "on the fly" during the build process as the result of some calculation or text manipulation is shown interactively immediately after each formula is entered. 5.1.2 Testing methods

Mobile Based Lan Monitoring And Control Software testing methods are traditionally divided into black box testing and white box testing. These two approaches are used to describe the point of view that a test engineer takes when designing test cases.

Black box testing

Black box testing treats the software as a black box without any knowledge of internal implementation. Black box testing methods include equivalence partitioning, boundary value analysis, all-pairs testing, fuzz testing, model-based testing, traceability matrix, exploratory testing and specification-based testing. Specification-based testing Specification-based testing aims to test the functionality according to the requirements. Thus, the tester inputs data and only sees the output from the test object. This level of testing usually requires thorough test cases to be provided to the tester who then can simply verify that for a given input, the output value (or behavior), is the same as the expected value specified in the test case. Specification-based testing is necessary but insufficient to guard against certain risks. Advantages and disadvantages The black box tester has no "bonds" with the code, and a tester's perception is very simple: a code MUST have bugs. Using the principle, "Ask and you shall receive," black box testers find bugs where programmers don't. BUT, on the other hand, black box testing is like a walk in a dark labyrinth without a flashlight, because the tester doesn't know how the back end was actually constructed. That's why there are situations when 1. A black box tester writes many test cases to check something that can be tested by only one test case and/or 2. Some parts of the back end are not tested at all. Therefore, black box testing has the advantage of an unaffiliated opinion on the one hand and the disadvantage of blind exploring on the other.

White box testing

White box testing, by contrast to black box testing, is when the tester has access to the internal data structures and algorithms (and the code that implement these)

Mobile Based Lan Monitoring And Control Types of white box testing The following types of white box testing exist: Code Coverage - creating tests to satisfy some criteria of code coverage. For example, the test designer can create tests to cause all statements in the program to be executed at least once. Mutation testing methods. Fault injection methods. Static Testing - White box testing includes all static testing.

Code completeness evaluation White box testing methods can also be used to evaluate the completeness of a test suite that was created with black box testing methods. This allows the software team to examine parts of a system that are rarely tested and ensures that the most important function points have been tested. Two common forms of code coverage are: Function Coverage, which reports on functions executed Statement Coverage, which reports on the number of lines executed to complete the test. They both return coverage metric, measured as a percentage.

Grey Box Testing

In recent years the term grey box testing has come into common usage. This involves having access to internal data structures and algorithms for purposes of designing the test cases, but testing at the user, or black-box level. Manipulating input data and formatting output do not qualify as grey-box because the input and output are clearly outside of the black-box we are calling the software under test. This is particularly important when conducting integration testing between two modules of code written by two different developers, where only the interfaces are exposed for test. Grey box testing may also include reverse engineering to determine, for instance, boundary values or error messages.


Mobile Based Lan Monitoring And Control

Acceptance testing

Acceptance testing can mean one of two things: A smoke test is used as an acceptance test prior to introducing a build to the main testing process. Acceptance testing performed by the customer is known as user acceptance testing (UAT).

Regression Testing

Regression testing is any type of software testing that seeks to uncover software regressions. Such regressions occur whenever software functionality that was previously working correctly stops working as intended. Typically regressions occur as an unintended consequence of program changes. Common methods of regression testing include re-running previously run tests and checking whether previously fixed faults have re-emerged.

Non Functional Software Testing

Special methods exist to test non-functional aspects of software. Performance testing checks to see if the software can handle large quantities of data or users. This is generally referred to as software scalability. This activity of Non Functional Software Testing is often times referred to as Load Testing. Usability testing is needed to check if the user interface is easy to use and understand. Security testing is essential for software which processes confidential data and to prevent system intrusion by hackers. In contrast to functional testing, which establishes the correct operation of the software (correct in that it matches the expected behavior defined in the design requirements), non-functional testing verifies that the software functions properly even when it receives invalid or unexpected inputs. Software fault injection, in the form of fuzzing is an example of non-functional testing. Non-functional testing, especially for software, is designed to establish whether the device under test can tolerate invalid or unexpected inputs, thereby establishing the robustness of input validation routines as well as error-handling routines. Various commercial non-functional testing tools are linked from the Software fault

Mobile Based Lan Monitoring And Control injection page; there are also numerous open-source and free software tools available that perform non-functional testing.

5.1.3 Testing process

A common practice of software testing is performed by an independent group of testers after the functionality is developed before it is shipped to the customer. This practice often results in the testing phase being used as project buffer to compensate for project delays, thereby compromising the time devoted to testing. Another practice is to start software testing at the same moment the project starts and it is a continuous process until the project finishes. In counterpoint, some emerging software disciplines such as extreme programming and the agile software development movement, adhere to a "test-driven software development" model. In this process unit tests are written first, by the software engineers (often with pair programming in the extreme programming methodology). Of course these tests fail initially; as they are expected to. Then as code is written it passes incrementally larger portions of the test suites. The test suites are continuously updated as new failure conditions and corner cases are discovered, and they are integrated with any regression tests that are developed. Unit tests are maintained along with the rest of the software source code and generally integrated into the build process (with inherently interactive tests being relegated to a partially manual build acceptance process). Testing can be done on the following levels: Unit testing tests the minimal software component, or module. Each unit (basic component) of the software is tested to verify that the detailed design for the unit has been correctly implemented. In an object-oriented environment, this is usually at the class level, and the minimal unit tests include the constructors and destructors. In computer programming, unit testing is a software design and development method where the programmer verifies that individual units of source code are working properly. A unit is the smallest testable part of an application. In procedural programming a unit may be an individual program, function, procedure, etc., while in


Mobile Based Lan Monitoring And Control object-oriented programming, the smallest unit is a method, which may belong to a base/super class, abstract class or derived/child class. Ideally, each test case is independent from the others; Double objects like stubs, mock or fake objects as well as test harnesses can be used to assist testing a module in isolation. Unit testing is typically done by software developers to ensure that the code other developers have written meets software requirements and behaves as the developer intended. Integration testing exposes defects in the interfaces and interaction between integrated components (modules). Progressively larger groups of tested software components corresponding to elements of the architectural design are integrated and tested until the software works as a system. Integration testing' (sometimes called Integration and Testing, abbreviated I&T) is the phase of software testing in which individual software modules are combined and tested as a group. It follows unit testing and precedes 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. System testing tests a completely integrated system to verify that it meets its requirements. System integration testing verifies that a system is integrated to any external or third party systems defined in the system requirements. Regression testing is any type of software testing which seeks to uncover software regressions. Such regressions occur whenever software functionality that was previously working correctly stops working as intended. Typically regressions occur as an unintended consequence of program changes. Common methods of regression testing include re-running previously run tests and checking whether previously fixed faults have re-emerged. Alpha testing is simulated or actual operational testing by potential users/customers or an independent test team at the developers' site. Alpha testing is often employed for off-the-shelf software as a form of internal acceptance testing, before the software goes to beta testing.

Mobile Based Lan Monitoring And Control Beta testing comes after alpha testing. Versions of the software, known as beta versions, are released to a limited audience outside of the programming team. The software is released to groups of people so that further testing can ensure the product has few faults or bugs. Sometimes, beta versions are made available to the open public to increase the feedback field to a maximal number of future users.

Acceptance testing can be conducted by the end-user, customer, or client to

validate whether or not to accept the product. Acceptance testing may be performed as part of the hand-off process between any two phases of development. 5.2 Debugging Debugging is a methodical process of finding and reducing the number of bugs, or defects, in a computer program or a piece of electronic hardware thus making it behave as expected. Debugging tends to be harder when various subsystems are tightly coupled, as changes in one may cause bugs to emerge in another.

5.2.2 Debugging process

Print debugging is the act of watching (live or recorded) trace statements, or print statements, that indicate the flow of execution of a process. Often the first step in debugging is to attempt reproduce the problem. This can be a non-trivial task, for example in case of parallel processes or some unusual software bugs. Also specific user environment and usage history can make it difficult to reproduce the problem. After the bug is reproduced, the input of the program needs to be simplified to make it easier to debug. For example, a bug in a compiler can make it crash when parsing some large source file. However, after simplification of the test case, only few lines from the original source file can be sufficient to reproduce the same crash. Such simplification can be made manually, using divide-and-conquer approach. The programmer will try to remove some parts of original test case and check if the problem still exists. When debugging the problem in GUI, the programmer will try to skip some user interaction from the original problem description and check if remaining actions are sufficient for bug to appear. To automate test case simplification, delta debugging methods can be used.

Mobile Based Lan Monitoring And Control After the test case is sufficiently simplified, a programmer can use debugger to examine program states (values of variables, call stack) and track down the origin of the problem. Alternatively a tracing can be used. In simple case the tracing is just a few print statements, which print out the values of variables in certain points of program execution. Remote Debugging is the process of debugging a program running on a system different than the debugger. To start remote debugging, debugger connects to a remote system over a network. Once connected, debugger can control the execution of the program on the remote system and retrieve information about its state . Post-Mortem Debugging is the act of debugging the (core) dump of process. The dump of the process space may be obtained automatically by the system, or manually by the interactive user. Crash dumps (core dumps) are often generated after a process has terminated due to an unhandled exception.


Mobile Based Lan Monitoring And Control 5.3 Test Cases

Test Case id

Test Case Name

To check if module responds correctly to any message sent from mobile

Test Description
Valid message received Wrong message format

Expected Result
Process started

Actual Result

Pass/ Fail

gets Process get Pass started on server machine not Pass any

Process wont Dose get started perform action


Login Page

Enter correct username and password. Empty and fields

Going on the Tabbed Portal with Home Page tab open.

Going on the Pass Tabbed Portal with Home Page tab open. Displays Error Pass Message Invalid username or password


Login Page

username Displays Error password Message Invalid username or password


Registra Empty any of the Displays Error Displays Error Pass tion Field & Click on Message Fill Message Fill Page Submit Up All Up All Entries Entries. Registra Fill All the tion Entries with Page already existing username.
Contact Page


Displays Error Displays Error Pass Message Enter Message Enter Another Another Username Username
Searches users Pass on Mapped-In and shows their Markers


Enter First Name Searches users and Click on on Mapped-In submit button and shows their Markers


Mobile Based Lan Monitoring And Control


6.1 Applications

Mobile Based Lan Monitoring And Control

LAN monitoring at the university/college level can be used for monitoring, logging and retention of network packets that traverse university networks. The goal of this project is to maintain confidentiality, integrity and availability of the university network infrastructure and information assets.

LAN Monitoring at the office level can be used to monitor the office LAN by the administrator at any time if at a particular point he/she cannot be present there. He/she does not have to depend on any third party information regarding the LAN and can instead check the LAN status himself using his mobile.

6.2 Future Enhancement

In its current version of the software, we have included basic functionalities to assist network administrators in their job. Network administration though, includes a wide range of responsibilities. In the future version to come, effort can be made to include as many functions of a network administration is possible. We are going to add this modules Chatting Compile And Run Java Program Provide Application for Mobile handset



Mobile Based Lan Monitoring And Control SMS remains the most efficient communication system for pushing the content on to the mobile devices. Usage of SMS has grown tremendously over the past few years and many SMS based applications are the most prevalent services in the wireless world today. SMS are already being used to control remote devices such as precision air-conditioning systems, building automation systems, monitoring the temperature and switching on/off electronic devices. Therefore adding SMS capabilities into your existing network and managing the deskstops and servers is the obvious step in going forward. The software developed is a server based software application that provides ability to send and receive SMS messages through GSM network and communicates through standard TCP/IP protocol. The software is capable of sending the notification to the network administrator on his mobile device and thereafter the corrective action can be taken by the network administrator by sending a SMS in a prescribed format. At present the software provides limited features which can be further extended such as hardware/software inventory of desktops on the network.



Mobile Based Lan Monitoring And Control

Java concepts - Java tutorial - Mobile concepts - Networking concepts - GSM modem concepts -

Java complete Reference by Herbert Schildt Microsoft Windows Server 2003 in 24 hours by Joe Habraken. Computer Networks by Andrew Tanenbum. Computer Networks by Douglas Corner Software Engineering by Roger Pressman Fundamentals of Software Engineering by Rajib Mall.