through a very basic text-based webserver, each co2 host can answer http GET requests. just point your webbrowser at a co2 host's address (http://<host>:<port>).

for example http://co2.mur.at:2003/ will take you to this here relay's interface.

the (rather poorly designed) page displays some of the host's system properties (software and hardware), a link to the methods-listing, and, if the server is a relay, a link to the list of currently registered satellites.
the method-page lists all publicly available method-calls, along with their help texts (python __doc__ strings) and signatures (how to use them). the satellites-page shows the registered satellites' properties from the relay's view. if you want to find out about a satellite's system properties, just point your browser there (simply copy/paste the host_id to your browser's location bar).

this fancy interface provides you with the same information as the built-in one, but it is much nicer and more intuitive. the downside of this is, it will probably not work with your browser out of the box. you'll need a java-plugin that can handle at least version 1.3 applets and you'll have to put the following lines in a file called .java.policy in your home directory:

grant codeBase "http://co2.mur.at/java/xmlrpc.jar" {
	permission java.util.PropertyPermission "sax.driver", "read";
};

do this before you open Co2View!

if you are using the java plugin from blackdown, you might have to run the applet as root once. this is obviously due to an installation error in both their jdk and jre, which sets the wrong permissions somewhere in the java home directory. when you run the applet as a user then, it should work. sorry, don't know about the interns, just the workaround...

one more thing: as the applet loads, a dialog will pop up, informing you that you are about to load a signed applet. just accept the certificate and start browsing the co2 network.
if you don't want to be bothered by the popup in the furure, install this certificate in your browser (just click on the link).
why all this fuss? because that's the way java applets work. the Co2View applet connects back to the relay and to the satellites, which is a thing that applets normally are not allowed to do.

what the displayed properties - in both, the text and the java, interfaces - mean:

system properties (available from relay and satellite):

start_time:       when was this server started? (timestamp: YYYY.MM.DD hh:mm:ss)
uptime:           for how long has the server been up? (seconds)
server_time:      the current server time (timestamp: YYYY.MM.DD hh:mm:ss)
co2_version:      the co2 version
maintainer:       the person/s who run/s ther server
maintainer_email: maintainer's email address
max_sats:         maximum number of satellites allowed to be registered simultaneously
plugins:          a list of loaded plugins
sw_platform:      the software platform of this implementation (name and version)
co2_author:       the author of the server implementation
hw_platform:      the hardware platform of the host running the server
hardware:         the hosts hardware (i486, i586...)
processor:        processor information
operating_system: the host's operating system
kernel:           the version number fo the system kernel

(depending on the operating system of the queried host, some values might be missing or unknown.)

satellite properties (satellites only):

addr:         the hosts address in the form: (<'host'>:)
host_id:      the ID the satellite was assigned by the relay at registration
ctime:        timestamp, the server's start time (YYYY.MM.DD hh:mm:ss)
plugins:      a list of loaded plugins (the actual 'content providers')
recv_count:   number of co2 calls relayed to the satellite
recv_time:    timestamp of most recently received message (YYYY.MM.DD hh:mm:ss)
send_count:   number of co2 calls sent by the satellite
send_time:    timestamp of most recently sent message (YYYY.MM.DD hh:mm:ss)
ping_count:   total number of pings sent to the satellite so far
ping_current: most recent pingtime (response delay) (milliseconds)
ping_max:     longest pingtime so far (milliseconds)
ping_avg:     average pingtime (milliseconds)
ping_min:     shortest pintime (milliseconds)
ping_fails:   number of failed (not answered) ping requests (reset to 0 on eventual successful ping)