Technion IIT
EE Dept., Software Systems Lab
Network Monitor
Project 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.
3.
4.
Example system set-up................................................................................................... 6
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
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.
5.
Agent .............................................................................................................. 33
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
Page 2
Network Monitor Project
Winter, 2008
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.
5.2.2.
5.2.3.
5.2.4.
5.2.5.
5.2.6.
Overall description ................................................................................................... 51
Worker classes ......................................................................................................... 51
Scheduler classes ..................................................................................................... 52
Main class................................................................................................................. 53
Factory classes ......................................................................................................... 54
Auxiliary classes ....................................................................................................... 54
6.
Summary ...................................................................................................... 55
7.
Future work .................................................................................................. 56
8.
References .................................................................................................... 57
Page 3
Network Monitor Project
Winter, 2008
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.
Page 4
Network Monitor Project
Winter, 2008
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.
Page 5
Network Monitor Project
Winter, 2008
2.1. Example system set-up
AGENT
Workstations
LAN # 1
AGENT
Workstations
Firewall
Workstations
LAN # 3
AGENT
Firewall
Workstations
LAN # 2
Workstations
SERVER APPLICATION
Workstations
DATABASE
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.
Page 6
Network Monitor Project
Winter, 2008
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.
Page 7
Network Monitor Project
Winter, 2008
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 objectoriented 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
Page 8
Network Monitor Project
Winter, 2008
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.
Page 9
Network Monitor Project
Winter, 2008
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 selfcontained 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.
Page
10
Network Monitor Project
Winter, 2008
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.
Page
11
Network Monitor Project
Winter, 2008
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:
Page
12
Network Monitor Project
Winter, 2008
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 primarykey 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 primarykey 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 occasionallyconnected 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
Page
13
Network Monitor Project
Winter, 2008
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 (Entityrelationship 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-toEntities 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.
Page
14
Network Monitor Project
Winter, 2008
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
Page
15
Network Monitor Project
Winter, 2008
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.
Page
16
Network Monitor Project
Winter, 2008
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”
Page
17
Network Monitor Project
Winter, 2008
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:
Page
18
Network Monitor Project
Winter, 2008
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:
Page
19
Network Monitor Project
Winter, 2008
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.
Page
20
Network Monitor Project
Winter, 2008
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).
Page
21
Network Monitor Project
Winter, 2008
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).
Page
22
Network Monitor Project
Winter, 2008
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.
Page
23
Network Monitor Project
Winter, 2008
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”.
3. “SetObj3ID” – same as “Set Obj1ID”.
4. “SetObj4ID” – same as “Set Obj1ID”.
Page
24
Network Monitor Project
Winter, 2008
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”.
3. “Set URL #3” – same as “Set URL # 1”.
4. “Set URL #4” – same as “Set URL # 1”.
Page
25
Network Monitor Project
Winter, 2008
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.
Page
26
Network Monitor Project
Winter, 2008
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).
Page
27
Network Monitor Project
Winter, 2008
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”
Page
28
Network Monitor Project
Winter, 2008
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
Page
29
Network Monitor Project
Winter, 2008
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:
Page
30
Network Monitor Project
Winter, 2008
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.
Page
31
Network Monitor Project
Winter, 2008
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.
Page
32
Network Monitor Project
Winter, 2008
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.
Page
33
Network Monitor Project
Winter, 2008
5. Implementation
5.1. Server
Detailed UML of the design can be found in the attached MS Visio file:
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.
The group includes following classes/interfaces:
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.
Page
34
Network Monitor Project
Winter, 2008
The group includes following classes/interfaces:
a. Agent, IAgentContainer, IAgentProvider, AgentMenager.
b. Host, IHostContainer, IHostProvider, HostMenager.
4. Creational classes, main class, mediator class, auxiliary classes.
The group includes following classes/interfaces:
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
Page
35
Network Monitor Project
Winter, 2008
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.
Page
36
Network Monitor Project
Winter, 2008
Figure: Implementation class diagram for policy classes
Page
37
Network Monitor Project
Winter, 2008
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.
Page
38
Network Monitor Project
Winter, 2008
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.
Page
39
Network Monitor Project
Winter, 2008
Page
40
Network Monitor Project
Winter, 2008
Page
41
Network Monitor Project
Winter, 2008
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).
Page
42
Network Monitor Project
Winter, 2008
Page
43
Network Monitor Project
Winter, 2008
Page
44
Network Monitor Project
Winter, 2008
Page
45
Network Monitor Project
Winter, 2008
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.
Page
46
Network Monitor Project
Winter, 2008
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.
Page
47
Network Monitor Project
Winter, 2008
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 publishersubscriber 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.
Page
48
Network Monitor Project
Winter, 2008
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.
Page
49
Network Monitor Project
Winter, 2008
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.
Page
50
Network Monitor Project
Winter, 2008
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 startup. This latter feature assures that an Agent needs to be configured only once (and not each
time the agent application starts).
Page
51
Network Monitor Project
Winter, 2008
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.
Page
52
Network Monitor Project
Winter, 2008
5.2.4. Main class
Page
53
Network Monitor Project
Winter, 2008
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.
Page
54
Network Monitor Project
Winter, 2008
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.
Page
55
Network Monitor Project
Winter, 2008
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.
Page
56
Network Monitor Project
Winter, 2008
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
Page
57