PingView is designed primarily to scan and report the status of devices in a local network and report status on internet hosts. However, what if you have several devices at another location, most of which are not directly accessible using global IP addresses or domain names? In other words, how do you use PingView to manage remote networks?
Local "sub-nets" (such as SOHO networks) usually reuse the same ranges of addresses over and over. For example, the address range of 192.168.1.1 to 192.168.1.254 is the standard default for most Linksys products. This means that not only are the majority of devices in a small network not addressible from the internet, but any two of them will almost certainly contain duplicate IP addresses.
The problem, then, is how does a system running in one network obtain status information about another network? There are two basic ways. First, the main system can ask the subordinate system periodically for information; this is called "pull" messaging because the main system is pulling (requesting) information from the subordinate system.
The alternative is called "push" messaging. In this case, the subordinate system sends its status information to the main system whenever it chooses.
What is the difference? In the real world it is primarily a question of accessibility. In the "pull" case, the machine being asked for information must have a static IP address or a domain name. In the "push" case, the machine receiving the messages must have a static IP address or domain name. In addition, an addressed machine must be configured so that the TCP port it uses is visible through any firewall or router that may be in place.
PingView can be configured to perform and utilize either "push" or "pull" messaging. You choose the type of messaging based on which end of the communications path is visible on the Internet; that is, which end has a known IP address or domain name.
PingView can be configured to act in several different ways. Let's call them "push", "store" and "pull".
Every PingView instance can do any or all of these operations.
Whichever end of the operation is running the server must have a static IP address or domain name, either on the Internet or on the enterprise LAN.
When using "Pull", there is no problem of identification because the "pulling" PingView directly calls the "storing" PingView. With "Push", several subordinate PingViews might be sending information to a "storing" PingView. Each PingView collection is assigned a globally unique identifier (GUID) at the time it is created. This GUID is used to identify which remote "pushed' collection is used. No PingView instance will maintain more than one copy of a remote collection. Copies are purged once they have gone "stale".
In a PingView collection, each "pulled" collection is represented by a "PingView Server" target.
PingView may act as both as a server and a client. When configured to act as a server, PingView monitors a particular TCP port number. When PingView "clients" (from anywhere) connect to the machine running PingView on the correct TCP port and with the correct password, they can request that PingView do one of several things:
For any of these operations to occur, the serving PingView must be correctly configured and its server must be running. To do this, you must configure the port number and password for the server (see Collection Properties).
Once a PingView instance's collection is configured to run as a server, the server will automatically start when the collection is started. In the lower right-hand corner of the main window (the 'status bar') there is a small image that will tell you the state of the server. A checkmark on a green background indicates the server is operational; a red 'X' on a yellow background indicates that the server is configured but is not running; a grey 'X' indicates that no server is configured. If you click on the image a dialog box will appear giving the specifications of the server (port, password, enablement, etc.).
Let's imagine a user on vacation. His "roaming" (away from home) PingView collection that he runs on his laptop just tests to see if internet access is available, along with, probably, his email servers and favorite web sites. But what about all the devices back home?
In the "roaming" PingView collection, the user adds a new node giving the domain name or IP address for the home machine. Instead of using IP or TCP "pinging", this new node type must be set as "PingView Server" (see Adding and Updating Targets). The port number and password must match the values chosen in the PingView running back at home.
When the roaming PingView collection is run and queries the new "PingView Server" node, it does so by requesting a copy of the remote server's PingView collection. This information is then incorporated into the roaming PingView's main window as though it represented a local system.
In other words, PingView can "pierce firewalls" if you allow it to. By configuring your modems and routers to pass communications on the PingView server port number (usually port 23809) to the machine running PingView, the remote server machine can now report its information to any clients anywhere in the world.
This capability is recursive; that is, it can be nested to any depth. For example, let's say you're in New York in a hotel. Your main office has a machine running PingView. If you have configured client-server behavior, you can see all the detail of the home office network from your New York hotel. To expand the example, assume your home office also has a separate sub-net for the storefront you maintain downstairs. If there is a PingView instance that sub-net there communicating with (i.e. sending it's collection to) the office's main PingView, that information will also be available in the PingView running in the main office and, hence, also be visible to you in New York.
By linking PingView instances in this way, you can logically monitor the status of diverse, independent networks. All it takes is a little configuration.
Obviously, to use this capability on the global internet, some machine on your business or home must be addressible by either a domain name or a fixed IP address. If you, like many other people, have a cable or DSL modem which occasionally changes IP address, you'll have to find a means to either 1) know the current IP address or 2) have a domain name that automatically adjusts to changes in IP addressing. The latter is also called "Dynamic IP Addressïng"; it's a service offered by several companies, including Dynip.com of Canada.
In addition, most firewalls will not, by default, allow incoming TCP connections to an arbitrary port on your server. To configure this you must program your router or modem to forward all communications on the chosen "remote PingView" port (usually 23809) to the server running PingView. The firewall running on the server machine must also allow incoming connections on that port.