Network Monitor Project - EEMB DERSLER · from SNMP devices found in the local network, pinging...

Technion IIT EE Dept., Software Systems Lab

Network MonitorProject report

Students:

Vitaly Zakharenko

Alex Tikh

Supervisor:

Isask'har (Zigi) Walter

2008 Winter

Network Monitor Project Winter, 2008

Contents 1. Project goal ...................................................................................................... 4

2. Introduction ..................................................................................................... 5 2.1. Example system set‐up ................................................................................................... 6

3. Technology overview ....................................................................................... 7

3.1. The .NET Platform ............................................................................................... 7

3.2. NET Framework .................................................................................................. 8

3.3. The C# Language ............................................................................................... 10

3.4. ADO.NET ........................................................................................................... 12

3.5. NET Remoting ................................................................................................... 15

4. User Guide ..................................................................................................... 17

4.1. Server ............................................................................................................... 17 4.1.1. Main menu ................................................................................................................... 17 4.1.2. Managing agents .......................................................................................................... 18

4.1.2.1. Agent management menu (menu # 1.) .................................................................... 18 4.1.2.2. Policy container menu (menu #1.1) ......................................................................... 19 4.1.2.3. Policy menu (menu # 1.1.5) ..................................................................................... 21 4.1.2.4. Measurement set menu (menu # 1.1.5.3) ............................................................... 22 4.1.2.5. Generic measurement settings menu (menu # 1.1.5.3.1) ....................................... 23 4.1.2.6. Measurement‐specific settings menu for SNMP measurement (1.1.5.3.1.4) ......... 24 4.1.2.7. Measurement‐specific settings menu for URL accessibility measurement (1.1.5.3.1.4) ............................................................................................................................... 25 4.1.2.8. Measurement‐specific settings menu for Subnet Ping measurement (1.1.5.3.1.4) 26

4.1.3. Managing results .......................................................................................................... 27 4.1.3.1. Report menu (menu # 2) .......................................................................................... 28 4.1.3.2. Results filter menu (menu # 2.1).............................................................................. 29 4.1.3.3. Measurement ‐ specific menu (menu # 2.4.) for SNMP measurement ................... 30 4.1.3.4. Measurement ‐ specific menu (menu # 2.4.) for HTTP URL measurement ............. 31 4.1.3.5. Measurement ‐ specific menu (menu # 2.4.) for Subnet Ping measurement .......... 32

4.2. Agent ................................................................................................................ 33

5. Implementation ............................................................................................. 34

5.1. Server ............................................................................................................... 34 5.5.1. Introduction.................................................................................................................. 34 5.5.2. Classes for managing Agents’ functionality .................................................................. 35

5.1.2.1. Policy classes ............................................................................................................ 35 5.1.2.2. SettingSet classes ..................................................................................................... 38


5.1.2.3. Setting classes .......................................................................................................... 39 5.1.3. Classes for management of measurement results ....................................................... 42 5.1.4. Classes for storing/accessing Agent, Host information ................................................ 46

5.1.4.1. Agent classes ............................................................................................................ 46 5.1.4.2. Host classes .............................................................................................................. 47

5.1.5. Main class, mediator class, creational classes, auxiliary classes .................................. 48 5.1.5.1. Main class................................................................................................................. 48 5.1.5.2. Mediator .................................................................................................................. 48 5.1.5.3. Factories ................................................................................................................... 49 5.1.5.4. Auxiliary classes ....................................................................................................... 50

5.2. Agent ................................................................................................................ 51 5.2.1. Overall description ................................................................................................... 51 5.2.2. Worker classes ......................................................................................................... 51 5.2.3. Scheduler classes ..................................................................................................... 52 5.2.4. Main class................................................................................................................. 53 5.2.5. Factory classes ......................................................................................................... 54 5.2.6. Auxiliary classes ....................................................................................................... 54

6. Summary ....................................................................................................... 55

7. Future work ................................................................................................... 56

8. References ..................................................................................................... 57


1. Project goal The goal of the project is to design and implement distributed network monitoring software.

The software should monitor the network from multiple locations and report results to a central workstation. At the central workstation the results should be stored, processed and displayed in form of statistics. The central workstation should be able to remotely configure functionality of the distributed monitors.


2. Introduction The problem, which will often arise, when monitoring a computer network from a single location, is that firewalls may considerably restrict communication between computers in a local network and computers outside that network. In our project we try to resolve the problem by monitoring the network from multiple locations.

We implement a central piece of software (the Server), which collects results of network activity measurements from distributed monitors (Agents).

An Agent performs network activity measurements and sends results to the Server. A regular network monitoring tool needs to communicate with computers in the entire network from a single location. An Agent, however, only monitors computers in the local network, to which it belongs, and is, therefore, much less restricted by firewalls.

Network measurements taken by Agents may include checking for strange network activities (e.g. port scan), monitoring traffic (e.g. using PCap driver), extracting SNMP information from SNMP devices found in the local network, pinging someone, trying to access a Web server and characterizing time required to load a Web page etc.

The Server collects results, stores them in a database and provides statistics for the entire monitored network. The Server also remotely configures the functionality of Agents.


2.1. Example system set‐up

DATABASE

SERVER APPLICATION

FirewallWorkstations

LAN # 1Workstations

AGENT

Firewall

AGENT

Workstations

LAN # 2Workstations

AGENT

Workstations

Workstations

LAN # 3

Fig.: System diagram

The figure depicts a network consisting of 3 local networks. The Server is located on the computer of a network administrator in one of the local networks, namely in LAN # 3. Each LAN has one Agent in it. Each Agents measures network activity in its LAN and reports results to the Server. The Server stores the results in database.

Since Agents only perform measurements inside the local network, to which they belong, the network measurements are not restricted by the firewalls on the boundaries between the LANs.


3. Technology overview 3.1. The .NET Platform When Microsoft announced C# in July 2000, its unveiling was part of a much larger event: the announcement of the .NET platform. The .NET platform is, in essence, a new development framework that provides a fresh application programming interface (API) to the services and APIs of classic Windows operating systems (especially the Windows 2000 family), while bringing together a number of disparate technologies that emerged from Microsoft during the late 1990s. This includes COM+ component services, the ASP web development framework, a commitment to XML and object‐oriented design, support for new web services protocols such as SOAP, WSDL, and UDDI, and a focus on the Internet, all integrated within the DNA architecture.

Microsoft says it is devoting 80% of its research and development budget to .NET and its associated technologies. The results of this commitment to date are impressive. For one thing, the scope of .NET is huge. The platform consists of four separate product groups:

• A set of languages, including C# and Visual Basic .NET, a set of development tools including Visual Studio .NET, a comprehensive class library for building web services and web and Windows applications, as well as the Common Language Runtime (CLR) to execute objects built within this framework.

• A set of .NET Enterprise Servers, formerly known as SQL Server 2000, Exchange 2000, BizTalk 2000, and so on, that provide specialized functionality for relational data storage, email, B2B commerce, etc.

• An offering of commercial web services, called .NET My Services. For a fee, developers can use these services in building applications that require knowledge of user identity, etc.

• New .NET‐enabled non‐PC devices, from cell phones to game boxes.


3.2. NET Framework Microsoft .NET supports not only language independence, but also language integration. This means that you can inherit from classes, catch exceptions, and take advantage of polymorphism across different languages. The .NET Framework makes this possible with a specification called the Common Type System (CTS) that all .NET components must obey. For example, everything in .NET is an object of a specific class that derives from the root class called System.Object. The CTS supports the general concept of classes, interfaces, delegates (which support callbacks), reference types, and value types.

Additionally, .NET includes a Common Language Specification (CLS), which provides a series of basic rules that are required for language integration. The CLS determines the minimum requirements for being a .NET language. Compilers that conform to the CLS create objects that can interoperate with one another. The entire Framework Class Library (FCL) can be used by any language that conforms to the CLS.

The .NET Framework sits on top of the operating system, which can be any flavor of Windows, and consists of a number of components, currently including:

• Four official languages: C#, VB.NET, Managed C++, and JScript.NET • The CLR, an object‐oriented platform for Windows and web development

that all these languages share • A number of related class libraries, collectively known as the FCL

The most important component of the .NET Framework is the CLR, which provides the environment in which programs are executed. The CLR includes a virtual machine, analogous in many ways to the Java virtual machine. At a high level, the CLR activates objects, performs security checks on them, lays them out in memory, executes them, and garbage‐collects them. (The Common Type System is also part of the CLR.)

The layer on top of the CLR is a set of framework base classes, followed by an additional layer of data and XML classes, plus another layer of classes intended for web services, Web Forms, and Windows Forms. Collectively, these classes make up the FCL, one of the largest class libraries in history and one that provides an object‐oriented API for all the functionality that the .NET platform encapsulates. With more than 4,000 classes, the FCL facilitates rapid development of desktop, client/server, and other web services and applications.

The set of Framework base classes, the lowest level of the FCL, is similar to the set of classes in Java. These classes support rudimentary input and output, string manipulation, security management, network communication, thread management, text manipulation, reflection and collections functionality, etc.

Above this level is a tier of classes that extend the base classes to support data management and XML manipulation. The data classes support persistent


management of data that is maintained on backend databases. These classes include the Structured Query Language (SQL) classes to let you manipulate persistent data stores through a standard SQL interface. Additionally, a set of classes called ADO.NET allows you to manipulate persistent data. The .NET Framework also supports a number of classes to let you manipulate XML data and perform XML searching and translations.

Extending the Framework base classes and the data and XML classes is a tier of classes geared toward building applications using three different technologies: Web Services, Web Forms, and Windows Forms. Web services include a number of classes that support the development of lightweight distributed components, which will work even in the face of firewalls and NAT software. Because web services employ standard HTTP and SOAP as underlying communications protocols, these components support Plug and Play across cyberspace.

Web Forms and Windows Forms allow you to apply Rapid Application Development techniques to building web and Windows applications. Simply drag and drop controls onto your form, double‐click a control, and write the code to respond to the associated event.


3.3. The C# Language The C# language is disarmingly simple, with only about 80 keywords and a dozen built‐in datatypes, but C# is highly expressive when it comes to implementing modern programming concepts. C# includes all the support for structured, component‐based, object‐oriented programming that one expects of a modern language built on the shoulders of C++ and Java.

The C# language was developed by a small team led by two distinguished Microsoft engineers, Anders Hejlsberg and Scott Wiltamuth. Hejlsberg is also known for creating Turbo Pascal, a popular language for PC programming, and for leading the team that designed Borland Delphi, one of the first successful integrated development environments for client/server programming.

At the heart of any object‐oriented language is its support for defining and working with classes. Classes define new types, allowing you to extend the language to better model the problem you are trying to solve. C# contains keywords for declaring new classes and their methods and properties, and for implementing encapsulation, inheritance, and polymorphism, the three pillars of object‐oriented programming.

In C#, everything pertaining to a class declaration is found in the declaration itself. C# class definitions do not require separate header files or Interface Definition Language (IDL) files. Moreover, C# supports a new XML style of inline documentation that simplifies the creation of online and print reference documentation for an application.

C# also supports interfaces, a means of making a contract with a class for services that the interface stipulates. In C#, a class can inherit from only a single parent, but a class can implement multiple interfaces. When it implements an interface, a C# class in effect promises to provide the functionality the interface specifies.

C# also provides support for structs, a concept whose meaning has changed significantly from C++. In C#, a struct is a restricted, lightweight type that, when instantiated, makes fewer demands on the operating system and on memory than a conventional class does. A struct can't inherit from a class or be inherited from, but a struct can implement an interface.

C# provides component‐oriented features, such as properties, events, and declarative constructs (called attributes). Component‐oriented programming is supported by the CLR's support for storing metadata with the code for the class. The metadata describes the class, including its methods and properties, as well as its security needs and other attributes, such as whether it can be serialized; the code contains the logic necessary to carry out its functions. A compiled class is thus a self‐contained unit. Therefore, a hosting environment that knows how to read a class' metadata and code needs no other information to make use of it. Using C# and the CLR, it is possible to add custom metadata to a class by creating custom attributes. Likewise, it is possible to read class metadata using CLR types that support reflection.


An assembly is a collection of files that appear to the programmer to be a single dynamic link library (DLL) or executable (EXE). In .NET, an assembly is the basic unit of reuse, versioning, security, and deployment. The CLR provides a number of classes for manipulating assemblies.

A final note about C# is that it also provides support for directly accessing memory using C++ style pointers and keywords for bracketing such operations as unsafe, and for warning the CLR garbage collector not to collect objects referenced by pointers until they are released.


3.4. ADO.NET ADO.NET is a set of computer software components that can be used by

programmers to access data and data services. It is a part of the base class library

that is included with the Microsoft .NET Framework. It is commonly used by

programmers to access and modify data stored in relational dratabase systems,

though it can also be used to access data in non‐relational sources. ADO.NET is

sometimes considered an evolution of ActiveX Data Objects (ADO) technology,

but was changed so extensively that it can be conceived of as an entirely new

product.

Architecture

ADO.NET consists of two primary parts:

Data provider

These classes provide access to a data source, such as a Microsoft SQL Server or

Oracle database and OLEDB data provider. Each data source has its own set of

provider objects, but they each have a common set of utility classes:

Connection: Provides a connection used to communicate with the data

source. Also acts as an abstract factory for command objects.

Command: Used to perform some action on the data source, such as

reading, updating, or deleting relational data.

Parameter: Describes a single parameter to a command. A common

example is a parameter to a stored procedure.

DataAdapter: A bridge used to transfer data between a data source and a

DataSet object (see below).

DataReader: Used to efficiently process a large list of results one record at

a time. It allows records to be accessed in a read‐only, forward‐only mode,

i.e., records have to be accessed in sequential order; they can neither be

randomly accessed nor can a record which has been processed previously be

accessed again.

DataSets

DataSets objects, a group of classes describing a simple in‐memory relational

database, were the star of the show in the initial release (1.0) of the Microsoft

.NET Framework. The classes form a containment hierarchy:

http://en.wikipedia.org/wiki/Command

http://en.wikipedia.org/wiki/Command

http://en.wikipedia.org/wiki/Parameter

http://en.wikipedia.org/wiki/Parameter

http://en.wikipedia.org/wiki/DataAdapter

http://en.wikipedia.org/wiki/DataAdapter

http://en.wikipedia.org/wiki/DataReader






A DataSet object represents a schema (either an entire database or a

subset of one). It can contain tables and relationships between those tables.

A DataTable object represents a single table in the database. It has

a name, rows, and columns.

A DataView object "sits over" a DataTable and sorts the

data (much like a SQL "order by" clause) and filters the records (much

like a SQL "where" clause) if a filter is set. An in‐memory index is used

to facilitate these operations. All DataTables have a default filter, while

any number of additional DataViews can be defined, reducing

interaction with the underlying database and thus improving

performance.

A DataColumn represents a column of the table,

including its name and type.

A DataRow object represents a single row in the

table, and allows reading and updating of the values in that row, as

well as retrieving any rows that are related to it through a primary‐

key foreign‐key relationship.

A DataRowView represents a single row of a

DataView. The distinction between a DataRow and DataRowView is

important when iterating over a result set.

A DataRelation is a relationship between tables, such as a primary‐

key foreign‐key relationship. This is useful for enabling DataRow's

functionality of retrieving related rows.

A Constraint describes an enforced property of the database, such

as the uniqueness of the values in a primary key column. As data is

modified any violations that arise will cause exceptions.

A DataSet is populated from a database by a DataAdapter whose Connection and

Command properties have been set. However, a DataSet can save its contents to

XML (optionally with an XSD schema), or populate itself from XML, making it

exceptionally useful for web services, distributed computing, and occasionally‐

connected applications.

ADO.NET and Visual Studio.NET

Functionality exists in the Visual Studio .NET IDE to create specialized subclasses

of the DataSet classes for a particular database schema, allowing convenient

access to each field through strongly‐typed properties. This helps catch more

programming errors at compile‐time and makes the IDE's Intellisense feature

more useful.


Entity Framework

ADO.NET Entity Framework is a set of data access APIs for the Microsoft

.NET Framework, targeting the version of ADO.NET that ships with .NET

Framework 3.5. However, it will be released as an out‐of‐band update after

both .NET Framework 3.5 and Visual Studio 2008 have shipped. An Entity

Framework Entity is an object which has a key representing the primary key

of a logical datastore entity. A conceptual Entity Data Model (Entity‐

relationship model) is mapped to a datastore schema model. Using the

Entity Data Model, the Entity Framework allows data to be treated as

entities independently of their underlying datastore representations.

Entity SQL is a SQL‐like language for querying the Entity Data Model (instead

of the underlying datastore). Similarly, Linq extension Linq‐to‐Entities

provides typed querying on the Entity Data Model. Entity SQL and Linq‐to‐

Entities queries are converted internally into a Canonical Query Tree which is

then converted into a query understandable to the underlying datastore

(e.g. into SQL in the case of a Relational database). The entities can be using

their relationships, and their changes committed back to the datastore.

http://en.wikipedia.org/wiki/SQL

http://en.wikipedia.org/wiki/Relational_database


3.5. NET Remoting .NET Remoting is a Microsoft application programming interface (API) for

interprocess communication released in 2002 with the 1.0 version of .NET

Framework. It is one in a series of Microsoft technologies that began in 1990 with

the first version of Object Linking and Embedding (OLE) for 16‐bit Windows.

Intermediate steps in the development of these technologies were Component

Object Model (COM) released in 1993 and updated in 1995 as COM‐95,

Distributed Component Object Model (DCOM), released in 1997 (and renamed

ActiveX), and COM+ with its Microsoft Transaction Server (MTS), released in

2000. It is now superseded by Windows Communication Foundation (WCF),

which is part of the .NET Framework 3.0. The .NET Framework 3.0 is also included

with the Windows Vista operating system.

Like its family members and similar technologies such as Common Object

Request Broker Architecture (CORBA) and Java's remote method invocation

(RMI), .NET Remoting is complex, yet its essence is straightforward. With the

assistance of operating system and network agents, a client process sends a

message to a server process and receives a reply.

Overview

.NET Remoting allows an application to make an object (termed remotable

object) available across remoting boundaries, which includes different

appdomains, processes or even different computers connected by a network. The

.NET Remoting runtime hosts the listener for requests to the object in the

appdomain of the server application. At the client end, any requests to the

remotable object are proxied by the .NET Remoting runtime over Channel objects,

that encapsulate the actual transport mode, including TCP streams, HTTP streams

and named pipes. As a result, by instantiating proper Channel objects, a .NET

Remoting application can be made to support different communication protocols

without recompiling the application. The runtime itself manages the act of

serialization and marshalling of objects across the client and server appdomains.

.NET Remoting makes a reference of a remotable object available to a client

application, which then instantiates and uses a remotable object as if it were a

local object.r However, the actual code execution happens at the server‐side. A

remotable object is identified by Activation URLs and are instantiated by a

connection to the URL. A listener for the object is created by the remoting

runtime when the server registers the channel that is used to connect to the

remotable object. At the client side, the remoting infrastructure creates a proxy


that stands‐in as a pseudo‐instantiation of the remotable object. It does not

implement the functionality of the remotable object, but presents a similar

interface. As such, the remoting infrastructure needs to know the public interface

of the remotable object before‐hand. Any method calls made against the object,

including the identity of the method and any parameters passed, are serialized to

a byte stream and transferred over a communication protocol‐dependent Channel

to a recipient proxy object at the server side("marshalled"), by writing to the

Channel's transport sink. At the server side, the proxy reads the stream off the

sink and makes the call to the remotable object on the behalf of the client. The

results are serialized and transferred over the sink to the client, where the proxy

reads the result and hands it over to the calling application. If the remotable

object needs to make a callback to a client object for some services, the client

application must mark it as remotable and have a remoting runtime host a

listener for it. The server can connect to it over a different Channel, or over the

already existent one if the underlying connection supports bidirectional

communication. A channel can be composed of a number of different Channel

objects, possibly with different heterogeneous transports. Thus, remoting can

also work across systems separated by an interconnection of heterogeneous

networks, including the internet. Type safety is enforced by the CTS and the .NET

Remoting runtime. Remote method calls are inherently synchronous;

asynchronous calls can be implemented using threading libraries. Authentication

and access control can be implemented for clients by either using custom

Channels or by hosting the remotable objects in IIS and then using the IIS

authentication system.


4. User Guide 4.1. Server

4.1.1. Main menu

Menu options:

1. “Manage agents” allows to

a. View status of agents

b. Change functionality of agents via changing agent policies

2. “View results” allows to

a. View results of measurements performed by agents

3. “Edit application settings” is currently empty.

4. “Exit”


4.1.2. Managing agents The application allows viewing status of known agents and agent management through definition of “policies” for ranges of IP addresses.

Each policy defines settings for each of the measurements performed by agents. A policy together with the IP address range, to which it applies, can be changed via Agent management menu, accessible by choosing option (1) from the Main menu.

Agent status (also accessible via Agent management menu) informs the user whether a given agent is currently connected and whether it is up‐to‐date (i.e. conforms to the policy, by which it is governed).

4.1.2.1. Agent management menu (menu # 1.)

1. “Manage agent policies” allows to

a. Change functionality of agents via changing agent “policies”.

2. ” View agent status” allows to

a. View list of known agent

b. For each known agent view whether it is currently connected and whether its settings are up‐to‐date (i.e. correspond to the highest priority policy covering the IP address of the agent). Example results:


4.1.2.2. Policy container menu (menu #1.1) Policy container menu allows viewing of existing policies and addition/removal of policies. It also serves an entry point to Policy menu (opened by choosing option 5), which in turn serves for editing of a given existing policy.

1. “List policies” allows to

a. View basic description and listing of all existing policies. Example result:

2. “Create new policy” allows to

a. Add new policy with default settings. The program shows basic description of the newly created policy. Example output:


3. “Remove policy”

a. User is requested to enter the id of policy to be removed. The program confirms policy removal. Example screen:

4. “Find policy for IP address” allows to

a. Find ID of a policy, which will be applied to agent at a given IP address.

5. “Edit/View policy”

a. Brings user to Policy Menu (1.1.5).

b. Allows the user to view and change settings belonging to a specific policy.


4.1.2.3. Policy menu (menu # 1.1.5) Policy menu serves for editing of the policy chosen in the previous stage in Policy container menu. Policy menu allows user to change measurement settings for agents governed by the policy and also to change the range of IP addresses of agents associated to the policy.

The Policy menu also provides an entry point to Measurement set menu, which serves to editing of measurement settings.

1. “Edit/view IpGroup” allows to

a. Change the range of IP addresses covered by the policy. Example output:

2. “Set priority” allows to

a. Change priority of the selected policy.

3. “Edit/view measurement settings”

a. Brings user to “Measurement set menu” (1.1.5.3).

b. Allows user to view/edit settings of measurements performed by an agent governed by the chosen policy (i.e. an agent, whose IP address falls within IP group of the chosen policy).


4.1.2.4. Measurement set menu (menu # 1.1.5.3)

1. “Edit/view measurement settings”

a. Allows to view and change the way an agent governed by the chosen policy performs a specific network measurement.

b. The user is requested to enter the index of a measurement, the settings of which he/she would like to view/change. The user is then led to GENERIC MEASUREMENT SETTINGS MENU (1.1.5.3.1).


4.1.2.5. Generic measurement settings menu (menu # 1.1.5.3.1)

Displays scheduler settings for the chosen measurement and allows the user to change the settings. Example menu screenshot:

1. “Set enabled”

a. Enables the scheduler of the measurement for agents governed by the edited policy.

2. “Set timer auto reset”

a. Turns on the auto‐reset mode of the scheduler of the edited measurement.

3. “Set timer interval”

a. Allows the user to set the interval property of the scheduler of the edited measurement.

4. “Edit/view measurement‐specific settings”

a. Brings the user to “Measurement‐specific settings menu (1.1.5.3.1.4)”.

b. Allows setting/viewing settings, which are specific to a given measurement.


4.1.2.6. Measurement‐specific settings menu for SNMP measurement (1.1.5.3.1.4)

The menu is intended to allow viewing/changing of setting specific to SNMP measurement.

Sample screenshot:

1. “Set Obj1ID”

a. Allows user to set the property Obj1ID of SNMP measurement.

b. Properties Obj1ID, Obj2ID etc. determine the Object identifiers of nodes, the values of which are communicated to the Server for each detected SNMP device.

2. “SetObj2ID” – same as “Set Obj1ID”.




4.1.2.7. Measurement‐specific settings menu for URL accessibility measurement (1.1.5.3.1.4)

The menu is intended to allow viewing/changing of setting specific to SNMP measurement.

Sample screenshot:

1. “Set URL # 1”

a. Allows user to set the property URL #1 of SNMP measurement.

b. The property URL #1 determines HTTP URL accessed by the measurement.

2. “Set URL #2” – same as “Set URL # 1”.




4.1.2.8. Measurement‐specific settings menu for Subnet Ping measurement (1.1.5.3.1.4)

The menu is intended to allow viewing/changing of setting specific to Subnet Ping measurement.

Sample screenshot:

1. “Set packet data size”

a. Changes size (in bytes) of data attached to ICMP packet.

2. “Set number of echo requests to send”

a. Changes number of ICMP packets to be sent to a host.

3. “Set timeout in milliseconds to wait for each reply”

a. Changes time interval, after which the packet is considered as lost.


4.1.3. Managing results The application allows the user to define the set of “interesting” measurement results. For this purpose the user can choose one of the measurements performed by agents and apply a filter to the measurement results. The measurement results can be filtered by IP address of agents, which performed the measurements, IP address of workstations being characterized by the measurements and time interval, in which the network measurements were performed.

Having defined a set of results of interest (or accepted the default one) the user can request the application to produce either a “raw” results report or a statistical report.

Raw results report should be used to obtain maximum of information on an event.

Statistical reports are measurement specific. They are not intended to provide most complete information on a network state/network event but to display the information in a compact and clear form.

The user is expected to first identify an interesting event from a statistical report and then, if necessary, to extract all available information from a “raw” measurement results report (after filtering of the result set).

The “raw” measurement result report and the statistical report can be produced to the screen or saved to a file.

On choosing View results option (option #2) in Main menu the user is prompted to specify the measurement, results of which he/she is interested to view/analyze.

Sample screen:

The user is then transferred to the Report menu (menu # 2).


4.1.3.1. Report menu (menu # 2) The upper part of the screen shows current settings of the measurement results filter. The filter is used to define the set of measurements of interest used to produce reports.

The menu provides an entry point (via option 1) to Results filter menu used to edit the result filter. The user is expected to first set filter values (having thus defined the set of measurement results of interest) and then to request the application to produce a report (via options 2, 3 or 4 of the menu).

Sample screenshot:

Menu options:

1. “Edit filter”

a. Changes measurement results filter used to define the set of “interesting” network measurement results. Brings user to Results filter menu (menu # 2.1).

2. “Produce raw result report to console”

a. Produces a listing of results in the form they were communicated to the server by the agents. The report is produced to the screen.

3. “Produce raw result report to file”

a. Produces a listing of results in the form they were communicated to the server by the agents. The report is produced to a text file.

4. “Produce statistical report”


a. Produces measurement‐specific statistical report. Brings user to Measurement‐specific statistical report menu (menu # 2.4).

4.1.3.2. Results filter menu (menu # 2.1) Changes measurement results filter used to define the set of “interesting” network measurement results.

Sample screenshot:

Menu options:

1. “Switch measurement”

a. Choose a different measurement for the reports.

2. “Set start date”

a. Specify the start date of the time interval of interest. Only measurements taken in this time interval will be considered.

3. “Set end date”

a. Specify the end date of the time interval of interest. Only measurements taken in this time interval will be considered.

4. “Set hosts IP address range”

a. Specify the range of IP addresses of “measured” hosts. Only measurements applied to IP addresses in this range will be considered.


5. “Set agents IP address range”

a. Specify the range of IP addresses of agents. Only measurements performed by agents in this range will be considered.

4.1.3.3. Measurement ‐ specific menu (menu # 2.4.) for SNMP measurement

The menu allows user to choose between different measurement‐specific statistical reports available for SNMP measurement. Currently, only one such report is available.

Menu options:

1. Report SNMP devices.

a. Produces report of all known devices, which respond to SNMP v.1.

Sample screenshot:


4.1.3.4. Measurement ‐ specific menu (menu # 2.4.) for HTTP URL measurement

The menu allows user to choose between different measurement‐specific statistical reports available for HTTP URL measurement. The 2 available reports supply total number of available measurement results, average time required to load a web page from a specific URL, percentage of access failures for each URL and also provide a listing of all URL access failures (within the result set of interest).

Sample screenshot:

Menu options:

1. “Report avg. URL access time”

a. For each of the 4 URLs used in the measurement the report provides average time required to load a web page from that URL and also shows the percent of failures to access that URL.

2. “Report URL access failures”

a. For each URL access failure the report supplies the inaccessible URL, IP address of the agent, which failed to access that URL, and the time.


4.1.3.5. Measurement ‐ specific menu (menu # 2.4.) for Subnet Ping measurement

The menu allows user to choose between different measurement‐specific statistical reports available for Subnet Ping measurement. The upper part of the screen displays the default report informing the user how many measurement results were considered for the report, how many pinged IP addresses never respond to ICMP (are always “dead”), how many pinged IP addresses are always responsive to ICMP (are always “alive”) and also how many addresses change their state.

Sample screenshot:

Menu options:

1. “List IPs always alive”

a. Lists all IP addresses, which always respond to ping (to ICMP).

2. “List IPs always dead”

a. Lists all IP addresses, which never respond to ping (to ICMP).

3. “List IPs changing their state”

a. Lists all IP addresses, which once respond to ping (to ICMP) and once do not respond.


4.2. Agent Agent performs a set of measurements specified by Server and communicates measurement results to the Server. Agent does not require any configuration except specification of the IP address of the Server. On Agent application start up the user is prompted either to accept or to change the current Server IP address setting. The server saves this setting in a file, so the user is always prompted with the last entered Server IP address. Agent is not intended to supply any information to the user of the local machine. For this reason, the screen only shows which measurements were performed by the agent and whether they were successfully delivered to the Server.


5. Implementation 5.1. Server Detailed UML of the design can be found in the attached MS Visio file:

uml3new1.vsd

5.5.1. Introduction All classes/interfaces belonging to the application can be divided in 3 groups:

1. Classes for management of Agents’ functionality.

The group includes following classes/interfaces:

a. Policy, IPolicyContainer, IPolicyProvider, PolicyManager.

b. SettingSet, ISettingSetContainer, ISettingSetProvider, SettingSetManager.

c. ISettingContainer, Setting, SettingA, SettingB, ISettingProvider, ISettingAProvider, ISettingBProvider,

d. SettingAManager, SettingBManager

2. Classes for management of network measurement results.


a. Measurement, Measurement A, MeasurementB.

b. IMeasurementProvider, IMeasurementProvider, IMeasurementAProvider, IMeasurementBProvider.

c. IMeasurementContainer, IMeasurementAContainer, IMeasurementBContainer

d. MeasurementManager, MeasurementAManager, MeasurementBManager

3. Classes for storing/accessing Agent, Host information.



a. Agent, IAgentContainer, IAgentProvider, AgentMenager.

b. Host, IHostContainer, IHostProvider, HostMenager.

4. Creational classes, main class, mediator class, auxiliary classes.


a. MainClass

b. IMeasurementFactory, MeasurementAFactory, MeasurementBFactory,

c. Mediator

d. Ip, IpGroup.

Note:

1. All classes, whose name includes ‘A’ or ‘B’ (e.g. SettingA, SettingB) are examples for classes serving a specific measurement.

2. We define and use the word “host” as a computer characterized by a measurement as opposed to “agent” defined as a computer performing a measurement.

3. The UML file should only be used as a schematic sketch of a class diagram. The implemented class diagram may differ from the one shown in the UML file.

5.5.2. Classes for managing Agents’ functionality

5.1.2.1. Policy classes Overall description

Policy incorporates an IP range of Agents governed by the policy and settings, which define functionality of Agents governed by the policy. All policy data is stored in database. In order to avoid problems related to synchronization between records in memory and data in database tables we decided to keep all the data in database and to define classes, which, though having an interface identical to that of a data record, contain no data in memory, but access that data in database. This strategy also avoids creation of data structures for keeping the data in memory.

Policy


Has an interface of a policy data record. Its properties provide access to fields defining the set of Agents, which will be governed by this policy (properties IpGroup and Priority), and the set of settings defining the functionality of Agents controlled by this policy (property SettingSet). Each Policy instance corresponds to a row in Policy table in the database, therefore the id the Policy contains is actually the identifier of the corresponding row in Policy table.

PolicyManager

PolicyManager is the only class accessing the Policy table in database directly. It implements both IPolicyContainer and IPolicyProvider interfaces. That means it both serves a container of Policy records and is also a service class of the Policy class (i.e. a Policy class instance uses PolicyManager to read values/forward changes from/to the database).

IPolicyProvider

Since Policy class does not require a container of Policy records for its functionality, but only requires a service class to communicate values of the properties to/from the database we derive the PolicyManager class from IPolicyProvider and let the Policy class see the PolicyManager as IPolicyProvider.

IPolicyContainer

Since PolicyManager implements the dual functionality of both a container and a service class for Policy class and since someone, who wishes to use it as a container, does not need the service class functionality we derive PolicyManager from IPolicyContainer and used it everywhere via this interface.


Figure: Implementation class diagram for policy classes


5.1.2.2. SettingSet classes SettingSet class provides an abstraction of the whole set of settings defining the functionality of an Agent falling within the IP range governed by a specific policy.

Similar to the Policy classes the Container‐Provider strategy is used, so that actually no data is stored in SettingSet class, but everything is stored in the database. SettingSet is used as a data record, however, a data record it is not – on every access to a property it communicates date to/from the data base. The latter is done via the ISettingSetProvider.


5.1.2.3. Setting classes SettingSet class instance (see above) provides an abstraction of a set of Setting class instances. A Setting and the 3 derived classes SettingSnmp, SettingWeb, SettingPing provide an abstraction of a data record defining functionality of a single measurement on the Agent side.

The abstract Setting class implements settings common to all network measurements. In the current implementation these are the settings of the measurement scheduler, since each network measurement on the Agent side has its own scheduler controlled by AutoReset, Enabled and Interval properties.

The 3 derived classes SettingSnmp, SettingWeb, SettingPing implement properties specific to each network measurement on the Agent side. They all implement the function Edit() defined as abstract in the base class Setting. This function provides a menu, which is specific to a measurement and through which settings specific to the given measurements can be vied/changed. Additionally, the 3 classes implement the Activate(ip) function, which communicates current settings to the corresponding measurement on the Agent side. Thus, the call of Activate(ip) of class SettingWeb will communicate the settings to the corresponding MeasurementWeb class on the Agent side. The latter property facilitates addition of new measurements, since a Setting class on the Server side communicates directly with the corresponding Measurement class on the Agent class, with no dependence on classes serving other measurements.

The classes follow the same container – provider pattern as the policy and the setting set classes. Beneath each specific SettingManager class (e.g. SettingWebManager) there’s a database table storing all the settings of the measurement for all policy instances (e.g. SettingWebManager stores data in SettingWeb database table). The class both implements a container and a service class for dataless records. To create proper abstraction the Manager classes therefore derive from a corresponding container interface and from a provider interface.

The figures below describe the implementation class diagrams of setting classes and the underlying database tables used to store policy and settings data.


5.1.3. Classes for management of measurement results

Measurement class and the 3 derived classes MeasurementWeb, MeasurementSnmp, MeasurementPing provide an abstraction of measurement results data records. The class pattern resembles that of the setting classes (see above). All these classes are dataless, all the data stored in database tables. Measurement class provides properties common to results of all network measurements, namely the properties HostIp (IP address of the characterized network device), AgentIp (IP address of the agent, which performed the specific network measurement) and Time (time and date of the measurement).

The measurement classes follow the same container‐provider pattern as setting classes, policy classes etc. There’s a difference, however. All the specific Manager classes implement the same interface IMeasurementContainer, which creates an abstraction of a container of measurement results. The interfaces IMeasurementWebContainer, IMeasurementSnmpContainer and IMeasurementPingContainer are used solely for remoting, i.e. the specific manager classes are used by the remote Agents via these interfaces. The interfaces allow logging of network measurement results. Similar to the setting classes the specific MeasurementManager classes implement the container interface IMeasurementContainer and the data record service interface IMeasurementProvider. Each specific MeasurementManager class further implements a function RunMeasurementSpecificMenu (), which produces a measurement – specific statistical report menu.

Beneath each specific MeasurementManager class there is a database table, where all data of the given network measurement is stored. (See the diagram of measurement results – related database table below).


5.1.4. Classes for storing/accessing Agent, Host information

5.1.4.1. Agent classes Agent classes are built using the same dataless record‐provider‐container pattern used throughout the design.

Agent class implements interface of a data record, while actually contains no data, but only a key for accessing corresponding row in Agent database table. Properties of the agent include its IP address, ID of the policy, to which the Agent is mapped, and the UpToDate property informing whether the agent’s functionality was updated to conform to the policy, to which it is mapped.


5.1.4.2. Host classes We define and use the word “host” as a computer characterized by a measurement as opposed to “agent” defined as a computer performing a measurement.

Host classes are built using the same dataless record‐provider‐container pattern used throughout the design.

Host class implements interface of a data record, while actually contains no data, but only a key for accessing corresponding row in Agent database table.

There is currently no much use in Host class as well as in Hosts database table, them providing access only to the IP property. As was explained in Future Work section of the final presentation, the raw measurement results should be summarized in form of statistics and stored in the Hosts database table. We expect the host classes will be of much use then.


5.1.5. Main class, mediator class, creational classes, auxiliary classes

5.1.5.1. Main class The class contains an entry point to the application, the Main() function.

The class is responsible for launching the creation of application instances and manages most of the application menus.

5.1.5.2. Mediator Mediator class follows the Mediator design pattern, the purpose of which is to decouple classes in a design. Mediator’s field reference most objects in the application and vice‐versa main application instances (such as containers) contain references to mediator (in form of delegates to Mediator’s methods using publisher‐subscriber design pattern), but not to one another. Mediator is updated of every event in one instance, which requires actions on the part of some other instance.


5.1.5.3. Factories Each measurement has a corresponding factory, which is responsible for instantiation of all classes belonging to the measurement (such as MeasurementManager and SettingManager). Since the main application framework uses the Managers only as containers the factory methods return references to container interfaces they implement.


5.1.5.4. Auxiliary classes Ip and IpGroup classes are used in operations with IP addresses and IP address ranges respectively.

MenuReturnParam structure is used by Main class for running the menu hierarchy.

The delegates are used for communication between instances in the design and the Mediator, i.e. for signaling to Mediator of some event, which requires update of some other instance in the design.


5.2. Agent

5.2.1. Overall description On startup the agent displays a small menu, then for each of network measurement two classes are instantiated, a Worker and a Scheduler. From that point on, the couple of classes performing a specific network measurement, a Worker and a Scheduler, continue independently of the MainClass and of classes performing other network measurements.

5.2.2. Worker classes Worker classes actually perform the network measurements.

Worker classes are remoted using the corresponding interface and their functionality is configured by the remote Server (by changing the class’s properties).

Worker classes are also remoting clients for they log network measurement results using the container interface of the corresponding MeasurementManager on the Server side.

The classes are serializable. Their fields, which define how the network measurements are performed, are stored to a file on each change and are read from a file on application start‐up. This latter feature assures that an Agent needs to be configured only once (and not each time the agent application starts).


5.2.3. Scheduler classes Scheduler classes contain an instance of a System.Timers.Timer class and implement functionality similar to that of that Timer class. When enabled the timer functions either in watch‐dog mode (AutoReset mode) or in a regular mode (non‐AutoReset mode). When in watch‐dog mode the Work function of the corresponding Worker class is launched on a new thread every period of time equal to the value of Interval property. When in regular mode the function Work is launched only once after Interval delay.

The Scheduler classes are remoted using the IScheduler interface. Each scheduler is therefore configurable by the Server. The Schedulers are serializable and store the configuration to file on each change, this assures the Schedulers needs to be configures only once.

Note: each of the scheduler has very similar functionality and they, in principle, could be implemented as a single Scheduler class, if not for the remoting.


5.2.4. Main class


5.2.5. Factory classes Each measurement has a corresponding factory class named MeasurementXXX, which is responsible for instantiation of Worker and Scheduler for that measurement.

5.2.6. Auxiliary classes Ip class is common with the Server application and serves for IP address manipulations.

ReachablityStub is remoted using the interface IReachabilityStub and is used by the Server to check whether a specific Agent is currently accessible.


6. Summary

• By planting an Agent in a LAN one can efficiently raise restrictions imposed by LAN’s firewall. Thus, one can effectively monitor computers as if they all belonged to the same LAN.

C# is perfectly suited for programming tasks addressed in the application.

The application profited greatly from OOD support of C#, from powerful dedicated class libraries, easy DB access (via ADO.NET) and modern Remoting mechanisms.

C# is also widely used and perfectly compatible with many other technologies provided by Microsoft.

Storing information to MS SQL server database file instead of a regular data file makes the data structure more orderly and simplifies synchronization issues of a multithreaded application.

The Server is much larger than the Agent largely due to the use of database in the Server.

The technique of Remoting, as opposed to Sockets, both simplified multithreading issues and contributed to the Object‐oriented structure of the application.

The Server and the Agent allow easy integration of additional network measurements. Classes enabling a specific network measurement can be removed or added without any effect on classes providing the application framework and classes enabling other network measurements.

The Server includes 124 source files and 25231 lines containing a space character,

The agent includes 30 source files and 1738 lines containing a space character.


7. Future work The program is implemented as a console application. GUI should be developed.

The DB file may grow too large when many network measurement results are accumulated over time. The results should therefore be periodically summarized in form of statistics and saved in Hosts DB table.

New complex network measurements may be introduced.

The scheduling scheme of the measurements may be elaborated. Currently there’re two scheduling schemes: periodic and one‐time execution.

The IpGroup class (see Implementation section) may be extended to support not only ranges of IP addresses but also sets of IP addresses.

Local database may also be added to the Agents, so that results of network measurements do not get lost in case of temporary communication disruptions between Agents and the Server. If the Server is inaccessible an Agent would save the measurement results to the local DB and send them to the Server later.

The Server may periodically check network statistics and produce alarm messages in case some section of the monitored network fails.


8. References [1] Cabrera H., Faircloth J., Chen P. ‐ C# for Java Programmers (2002)

[2] Mastering C# database programming /Jason Price. San Francisco, Calif.: SYBEX, c2003.

[3] C# Network Programming by Richard Blum ISBN:0782141765 Sybex © 2003

Network Monitor Project - EEMB DERSLER · from SNMP devices found in the local network, pinging...

Documents

Transcript of Network Monitor Project - EEMB DERSLER · from SNMP devices found in the local network, pinging...