|
|
||||
|
|
||||
|
|
||||
|
Softpedia guarantees that Active IP Sensor is 100% CLEAN, which means it does not contain any form of malware, including but not limited to: spyware, viruses, trojans and backdoors
|
||||
|
||||
|
|
||||
|
|
||||
|
|
||||
|
Key Benefits |
||||
|
o Active IP Sensor
lets you watch all incoming and outgoing IP port connections in flight. Active
IP Sensor listens for connected IP ports as they are formed,
progress and retire and displays them in a tree view. Active IP Sensor lets you record and
share Active IP Port snapshots
or histories with remote clients that are running Active IP Sensor. o Active
IP Sensor can listen on several remote Active IP Sensors that are recording their activity in a
history file. Several Active IP Sensors
can simultaneously record their activity in a single history file shared on a network folder. o After each
sample, an Active IP Sensor client
interrogates its internal Filter and Alarm list for any Filter conditions that might
have appeared in the sample and invokes the specified Alarm action for it. o Active
IP Sensor Enterprise includes a portable database
interface and schema that can be used with all popular databases. This allows
Active IP Sensor to form strategically
distributed data collection points around a LAN
supplying datasets for warehouses or histories
for trending and forecasting databases. o A
comprehensive and flexible reporting suite allows for the creation of
periodic and dynamic reporting in a variety of
formats. This allows Active IP Sensor
to drive and measure network usage patterns as well as
acting as a real time LAN guardian. o A simple,
fast messaging protocol and client
are used to capture and transmit IP port activity on a remote node. Active IP Sensor Enterprise provides an equivalent UNIX client that permits remote sampling on SMB aware servers allowing Active IP
Sensor to monitor and control all nodes in a
typical LAN. o Active IP Sensor collects IP
data from the local execution environment (or remote environments if Active IP Sensor
is recording activity there in a history file) via an asynchronous proxy server (IPSensorProxy.exe). This disconnects IP sensor updates from multiple nodes
and allows them to report their current IP connections in parallel. IPSensorProxy.exe operates a custom scheduling algorithm and internal thread
pool (see Active IP Sensor Architecture).
The intent of the IP Sensor Proxy
and its Scheduler is to monitor thousands of nodes
on a LAN while maintaining a fixed resource usage footprint
on the monitoring node. o ActiveIPSensor.exe is a client container that presents a user interface. Each IPSensorProxy.exe thread is represented in a client tree view. Client threads participate in the proxy server handshaking illustrated in Active IP Sensor Architecture and are themselves double-buffered against the resulting node streams. Clients maintain a list of buffers, alternating roles between data collection and data display at the end of each complete sample. This helps smooth out data collection updates in the client`s tree view. o The ability
to comfortably buffer several hundred concurrent
Active IP Sensor listeners and
writers, implement any distributed architecture using remote history
file recordings and a highly configurable filtering and alarming framework are the primary
sources of Active IP Sensor`s power. A LAN
Manager can quickly and easily create semi-autonomous monitoring networks
composed of cascading and closed alarming client systems running in the background using Active IP
Sensor. Coupled with a portable database interface,
remarkably powerful and robust network management and control can be achieved
at vastly reduced cost and production impacts compared
with most other available products. |
Active
IP Sensor shows the executables that have
created a port connection in real time. Click a node on a sensors tree view to display
the nodes properties.
Active
IP Sensors UNIX client allows port monitoring on UNIX servers such as Linux as well as Windows hosts.
Active
IP Sensor senses local or
remote port activity in either Snapshot or History mode selected by clicking the graph next to the flashlight icon in the status bar.
|
Theory of Operation The following discusses some of the proprietary architectures available only in Active IP Sensor. All information provided is the exclusive property of Morning Glory Technologies and may not be
reproduced or copied in any form. o Active IP Sensor is non-intrusive.
It issues dynamic scripts and creates local file system objects in order to
implement a communication pipe for sending commands and getting their outputs
or status. There are no ports opened or any connections made
by Active IP Sensor. It simply
parses the script output (the tree view)
and writes the results in a file (Listen/Record
mode). This makes Active IP Sensor nearly impervious to a particular Windows
version or server type since only basic network I/O operations is used. There
is no SNMP or .NET
infrastructure to configure. There are no firewall issues to content
with. Active IP Sensor and IP Sensor Proxy
are completely self standing and do not depend on any external processes to
operate correctly. Only the ability to read a file on a shared network folder
is required to use Active IP Sensor to
monitor remote nodes. o Client
threads pipe their output to text files. IP
Sensor Proxy parses this
text file on behalf of client threads to get the needed output. The last
message written by a thread to a text file is an END OF PROCESSING token. Active IP Sensor monitors
these text files for the appearance of this token with a timeout (currently 64 seconds).
This allows asynchronous scripts to inform Active IP Sensor when
they have completed and permits Active IP
Sensor to form synchronous, serial data sources from them. This
sort of buffering is most evident while streaming trace route outputs, which are inherently
asynchronous but asynchronous streaming
is the dominant theme throughout Active IP
Sensor and is used to:
o Issue high latency queries across networks. o
Listen for real time
remote Active IP Sensor Recordings. o
Find Local IP processes and
their run time components. o All are
examples of different asynchronous requirements in Active IP Sensor each with unique streaming
characteristics. Yet, they are all implemented using nothing more than simple scripts, text files and a
few timers. Active IP
Sensor does this to avoid introducing any IP artifacts while sensing IP
port activity and to ensure the broadest range
of run time environments for Active IP
Sensor to operate in. |
|
o Referring
to Active IP Sensor Architecture
below, Active IP Sensor is a
client/server application composed of a client UI (ActiveIPSensor.exe)
and a multi threaded server (IPSensorProxy.exe)
that supplies clients with active IP port information from local or remote
network nodes. The client UI starts and stops
server threads. A server thread can refer to a local or remote network node.
The proxy server separates active IP port sensing operations from client
operations so that both can run independently of each other. The
server interrupts the client when the server scheduler has enabled the
clients thread. The server scheduler itself is a client thread added during
initialization. It is a special client thread referred to as Prime in the below drawing. A Prime thread is
distinct from other threads in that only it can run the servers scheduler
code. This allows for multiple or dynamic schedulers
in future releases. o The
scheduler communicates with clients using asynchronous interrupts.
When a client thread has been enabled, the client stops its current activity and
requests a data sample from the server. It then resumes its activity. When
the server has gathered a single sample, it again interrupts the client to
inform it that there is data ready. The client
stops its current activity and processes the server data. When the server has
streamed all samples, the client is interrupted (End of Stream). The client inspects
nodes from the previous sampling and removes those missing so that only nodes
from the current sample are displayed. The client thread then resumes its
activity until it is scheduled again. o Each client maintains a timer it starts
when IP Sensor Proxy has enabled its thread
and the client requests a sample. If IP Sensor Proxy
doesn`t respond with a data ready interrupt
within 3 seconds, the timer expires and the client Busy
animation is shown in its root node. If data ready
interrupts are received in time, the client disables the timer before the Busy animation can start. o Clients convey samples into a capture
buffer until IP Sensor Proxy raises the End of Stream interrupt. The current capture buffer
is then switched with the current display buffer using a multi-state flip flop that indexes an array of
buffers in order. This permits client operations to take place while samples
are simultaneously being gathered by IP Sensor Proxy
in the background. o The server
operates on a thread pool maintained by each client.
Server parameter CONCURRENT_THREADS enforces a limit on the maximum
number of client threads that can be concurrently running. IP Sensor Proxy operates its scheduler algorithm
periodically. The interval is controlled by the SCHEDULER_INTERVAL
parameter (currently every 5 mSecs). The scheduler algorithms are intended to
ensure that enabled threads reach a stable average quickly so that extremely
active threads won`t starve others of scheduler cycles. This means that the server appears the same to the system
no matter if there are 10 threads in the server pool or 10,000. These parameters
can be specified at run time via the client Scheduler tool.
o While a
thread is actively sampling, the server raises data ready interrupts
for each client thread it has enabled. THREAD_PRIORITY
specifies how many data interrupts are generated before the thread is
returned to the scheduler pool. The THREAD_PRIORITY
value is also used to bias the scheduler pool
thereby increasing or decreasing the chances that the scheduler will enable
that thread before the others. Higher thread priorities cause more data ready
interrupts. Lower values cause a client thread to update slower. o The IP Proxy server can sense IP port activity from the
local environment of from remote environments that
are recording their samples with Active IP Sensor.
Each client maintains a list of filters and alarms.
After each sample, the list is interrogated and if the sample contains a
filter item for one of the sampled nodes, the specified filter alarm action
is invoked. |
|
|
|
|
|
|
Send mail to martinj@morningglorytech.com with questions or
comments about this web site. Last modified: 01/03/2010 This
project was created by Jeff Martin
(available 01/2010)
This site is monitored by
|
Morning
Glory Technologies prefers
Development
Tools This site is
maintained using
This
site is
This
server is
|
Copyright Morning Glory
Technologies. All Rights Reserved