What's up with Appchkr?

Today Appchkr release 1.20 was published on the website.  This release contains the new Appchkr type "Inetchkr" to track performance of various paths thru the public Internet.  Performance here means connect time latency primarily, with uptime a secondary factor.  Since this release represents a significant step up in functionality the release number has been jumped from 1.10 to 1.20, with the intervening release numbers left unused, as is done for all such releases.

 

Internet performance tracking uses many of the native features of the leading Appchkr types, with a couple small changes, and one very significant addition:  A selection of pre-configured cfg files covering all the major areas of the Earth is being provided to get new users tracking immediately, without effort.  Selection of the targets for these files requires some thought and testing. To assess a geographical area the targets should be as uniformly distributed throughout that area as possible.  From a practical standpoint this means selecting the major cities in that area, as uniformly distributed as feasible.  In addition the targets should be ones whose server(s) are at a single point, or several very nearby points, so as to define a single shortest path from that Inetchkr to the target.  Large organizations have servers and DNS distributed throughout the area they serve so that no client has to wait long for a response.  Good for them and their users but this arrangement generally makes them unsuitable as targets.  Even though headquarters may be at a defined physical point on the Earth their Internet presence is spread throughout. 

So choosing a site with a presence at only one point or a few close by is the important second step.  This supposition can then be tested by checking DNS records, whois, and traceroute for each selected site.  Although one or the other of these may be partially or totally blocked the others can help to work around that.

The third factor is to use sites with sufficient power to well tolerate the additional load of the performance polling packets, and to have a very high uptime and stable latency. This requirement implies selecting sites from what might be termed the second tier of the Internet:  Those which are large and powerful enough, but not so large as to need and use a distributed server/DNS system.  In a sense this translates into targeting sites of sizeable organizations whose focus is primarily local rather than regional or global, such as a city government (but avoiding any distributed travel promotion site of the city. These may sometimes be handled by separate organizations.)

These are the considerations going into the creation of those pre-configured cfg files, which will be ongoing thru the next several releases.   One world-wide file of 10 tracking targets for free mode starts things off in this release and will help refine the selection concepts by actual use and testing over the next few weeks.  

Of course there is nothing that requires the performance tracking to attempt to cover any specific geographic area.  That is simply a convenient starting point.  It could just as well target any group of endpoints desired, on either the public Internet or on any private network using IP/TCP. 

And likewise it needn't use only web sites.  They happen to be a convenient starting point as well.  Any Appchkr checkable endpoint can be used for one, many or all endpoints in a tracking cfg file.  The key factor is just high uptime and low latency variation of that endpoint.