Defining the Need

Many home and small business offices expand regularly, but there rarely are trained personnel to maintain and diagnose them.  Even if the installation is done professionally or simply put together by a friend who purports to be a "guru", many such networks suffer erratic performance and outages that cannot be diagnosed by the people who use them.

PingView attempts to solve this problem by having a simple "wizard" to create a network collection; running the collection produces a simple diagnostic failure indication.  After PingView's wizard is run, the network administrator can augment the information with topological knowledge, device location and repair strategy information.  This will, it is hoped, enable even an average user to keep a network up whenever possible.

Flaky Networks, Flaky Servers

Networks go down.  This is an obvious but complex truth, since we must first define what we mean by "the network".  For most users, it's everything they normally use to conduct their business.  Over the years, I have had direct connections, DSL connections, cable connections and wireless connections.  All of them fail sometimes, and sometimes the reasons are both esoteric and transient.

For example, one very pesky problem is DNS failure.   Since almost all ISPs default to configuring systems to use their DNS servers, any failure in their servers appears as a "down" network to normal users.  Why?  Because they can't transform a domain name to an IP address, and hence can't load a web page.  All reported errors are ignored, as they should be, since, as an example, Microsoft's Internet Explorer gives the same error message whether your network cable is unplugged or the ISP's DNS server has just failed.

PingView lets users define "vital" and non-vital elements.  Vital elements are those whose absence would quickly be viewed as a "down" condition.  Non-vital elements are those that are used sporadically and where delays are tolerated.

In addition, the checking of whole legs of network topology can be quickly enabled or disabled.  This is done by marking them as "Ignore".  No pings are produced for these elements, but users can either ping them manually or un-ignore them to see their status.

Viewing the Network

Ethernet networks and IP-over-Ethernet configurations are always arranged in a formation known as a "star".  The apex of the star is usually a router or hub, most of which have their own IP addresses and respond (or can be configured to respond) to ICMP ping messages.  That apex then connects as one of the branches of a new "star", and so on until the Internet backbone is reached.

The idea behind PingView is that any machine's "local" view of the network can be encapsulated in a single collection.  If this collection is moved to another machine that is potentially behind a different router, the new router can be added as a target and the elements can simply be dragged and dropped into the proper place; the result is then saved onto the new computer.  This is very easy to do in PingView, but it does require a certain level of knowledge about the network topology.  Newer capabilities such as "Network Location Awareness" could augment this, but that would necessarily be in a later version.

The Larger View

Many if not most of today's users consider parts of the Internet to be part of their network.  This is true of small businesses in particular because their web sites are almost always hosted elsewhere, sometimes not even in the same state or country.

PingView does not care what ensemble of devices or domain names the user considers "the network".  As long as the targets are properly nested in packet routing order, the results will be obvious to any reasonably experienced user.

Managing Peripherals

More devices are being developed that sit directly on a local IP/Ethernet loop.  Modern printers, backup systems, video equipment, entertainment centers and other devices are often "Network ready" or communicate only via Ethernet.

In my case, for example, we have an H/P printer directly connected to Ethernet and a remote SlingBox device available through a firewall on a domain I support.  These devices are not always necessary every day, but having an easy means to test their availability is very useful.

Piercing the Vail: Remote Monitoring

The final piece of the PingView puzzle is remote monitoring.  It often happens that an organization has several SOHO or small networks in different locations.  Monitoring each of these independently is difficult, particularly while traveling.  PingView makes this easy by providing a "remote access" view into any network on where PingView is running on a machine.

Consider a situation where a business has two sites; a warehouse and a main office, for example.  If a PingView collection is created in the warehouse and runs continuously on a server in that warehouse, that PingView instance can be configured to report its current status to any other legitimate version of PingView.  Another copy of PingView would be running on a server in the main office, and it would have the warehouse's server configured as a "PingView Server" target. 

Marking the appropriate targets in the warehouse and main office as "vital" will allow the network administrator to get virtually instantaneous reports of the status of the entire network in a simple "thumbs up or down" fashion.

There are other remote monitoring options.  Remote PingViews can forward status information to central PingView instances if that configuration is easier.  In this case, the remote targets are configured as "Pushed Client" targets.

Since there is no limit to the depth of remote access, PingView servers could be used to monitor extensive networks across any number of DMZs or firewall-partitioned subnets.