Note about the home page:
This page is a bit incomplete right now; just a brief
description and
links to the files.
FreeNote is a distributed latency and availability monitoring system. It is comprised of three parts: the Dispatch Server (which manages jobs), the Probe (the distributed component which performs the jobs and is licensed under the GPL), and the Collection Server (to which the Probe reports its results). In gathering and reporting this data, our goal is nothing less than to make the Internet better.
A user submits a request to the Dispatch server with a URL to monitor. When a probe checks in, the Dispatch server selects a few URLs for the probe to hit. The probe simulates a user viewing the page by getting the page and any components (like images, flash animations, etc.) on it. The probe then connects to the Collection server and reports how long it took to view the page, including, for example, how long it took to connect, how long it took to resolve the domain name, and other useful information.
Later, after a few probes have checked the page, the user can use tokens to start running reports. The reports contain data reported by the probes and processed by the Collection Server. Is my site slow from Europe? How fast is it from AT&T's backbone? Is the bottleneck in the DNS or the routing? Is my ISP not delivering?
Tokens are the 'currency' users need to run reports. A user gets tokens by running a probe. Each probe is associated with a team. When a probe performs a job, the team gets tokens. Tokens can be exchanged for reports. You can start a team by visiting the main page.
There are four main reasons:
The Probe Monitor (my personal favorite part) is pre-alpha (read: I haven't had time to implement it fully) right now. In the source tree, in doc/examples, you can find three small examples of how it would work. The probe spews to UDP/14597 with information about its current status and the results from the jobs it runs. (Note that these are jobs assigned by the Dispatch Server, which sends out jobs based on your probe's geographic location, backbone, etc. There won't necessarily be a correlation between the jobs your probe runs and what URLs you are monitoring.)
A probe monitor can listen on that port and watch the data that comes through, do a little analysis, and draw something either pretty or interesting on the screen. doc/examples/ncpm.rb (a sloppy 60-minute proof-of-concept), for example, does a whois, and keeps track of download speeds from that CIDR. We plan at some point to have an Xscreensaver that does a cool graphical representation of the data, but for now we're all busy with 'real' work. :)
If you'd like to code your own probe monitor, we'd love to include it in the source tarball. But you should be warned that the format of the messages the probe sends will likely change, as this part is still under development and the current format of the data is a little ad-hoc.