Morning Glory Technologies

Active IP Sensor

HomeProductsServicesNewsMartin Home


Download Active IP Sensor

Release Notes


Active IP Sensor is 100% Verified has checked Active IP Sensor on Apr 22, 2010 for the viruses, Trojans, adware, spyware, malware and backdoors containing. We guarantee that Active IP Sensor is Verified, which means that does not contain any malicious components.

Please be advised that our system constantly scans the programs present within our website and if this software is to be found infected in the future, this certification award will be canceled.


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 guarantees that Active IP Sensor was tested by antivirus program and is absolutely clean, which means it does not contain any form of malware, including computer viruses, adware, trojans, spyware, rootkits, badware and other malicious and unwanted software.




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.

Active IP Sensor Architectures:


o  In the following diagram, it can be seen that Active IP Sensor is actually composed of two executables. Client threads are created by ActiveIPSensor.exe which could be running anywhere. Client threads are capable of receiving the data streams created by other client threads in addition to their own (local) IP port state. Each client environment contains a Thread Server (IPSensorProxy.exe) it creates at startup that communicates with the local client asynchronously.


o  IPSensorProxy.exe is responsible for sensing local IP port activity or for reading IP port activity from a remote client (ActiveIPSensor.exe) that is recording their local IP port activity in Active IP Sensor (.ais) format.


Asynchronous Client Threads


Remote pipes


A Client (ActiveIPSensor.exe)

Local/Remote Threads:


A Client Proxy Server (IPSensorProxy.exe)

Scheduler Algorithms

Thread Pool


A Client Proxy Server (IPSensorProxy.exe)

Scheduler Algorithms

Thread Pool


A Client (ActiveIPSensor.exe)

Local/Remote Threads:


A Client (ActiveIPSensor.exe)

Local/Remote Threads:



o  One or more clients (ActiveIPSensor.exe) communicate with a local Proxy server (ActiveIPSensor.exe). Each client can add one or more threads to the Proxy servers thread pool. A thread can refer to a local or remote communication pipe. A communication pipe is a file that contains Active IP Sensor (.ais) formatted messages. A client can read or write to both local and remote pipes via its local Proxy server. Several clients can read and write into the same communication pipe (yellow in the above diagram). This architecture distributes both the data collection nodes and their end points (pipes) so that either can exist in different environments.


o  When a client first starts up, it adds a special thread called Prime. This thread is always scheduled and is actually running the scheduler functions. It creates a new thread pool and timers. It calls scheduler functions to acquire IP Port samples (either locally or from a remote recording), format AIS (Active IP Sensor) messages and raise asynchronous events for the client thread passing the AIS messages to them.


o  IPSensorProxy.exe also maintains a class of threads called Command threads. These threads don`t acquire IP port state information, but dispatch discrete commands in the clients` execution space and then asynchronously stream the commands results using the same signaling as AIS messages.

Active IP Sensor client/proxy server communications:


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 ready 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.




Download Active IP Sensor


Release Notes




NewsMartin Home

Send mail to with questions or comments about this web site. Last modified: 05/17/2010

This project was created by Jeff Martin




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