The Noctum Design Uptimes Project
 
Home
Login
Create an Account
Statistics
Download Clients
FAQ
Forums

This server's uptime:
Uptime

The Uptimes Protocol (rev. 4.2)

What is this document about?
This document will describe the 4th revision of the uptimes protocol, used to communicate between the uptime server and its clients.

HTTP Protocol
As of revision 4, data is sent using the HTTP protocol instead of using an own TCP/IP stream. This way clients behind a firewall/proxy can use the client too. In particular all clients POST a request to the uptime server which returns a simple text string displaying the result. To make sure nobody can alter the data of other hosts the uptime server requires authentication.

General information
In order to work, a client must...

  • Use the HTTP protocol
  • Send the uptime at most once every 30 seconds
  • Send the uptime at least once every 10 minutes
  • Use the specifications as noted below

The HTTP header
A header would look like this:

POST /server.html HTTP/1.1
Host: uptimes.noctumdesign.com
Connection: Close
User-Agent: upclient/4.20/myclient-1.00
Content-type: application/x-www-form-urlencoded
Content-length: 7225
  • "POST /server.html HTTP/1.1"
    We are POSTing data to the uptime server located at /server.html. We use the HTTP/1.1 protocol.
  • "Host: uptimes.noctumdesign.com"
    The data should be posted to the server uptimes.noctumdesign.com. Clients should not use numeric IP's since the server can change location.
  • "Connection: Close"
    We don't want Keep-Alive connections because there's only one request.
  • "User-Agent: upclient/4.20/myclient"
    This line identifies the client. It should always be in the form of "upclient/version/identifier", where version is the protocol being used and identifier is the name of the client you wrote (for example "myclient" or "javaclient")
  • "Content-type: application/x-www-form-urlencoded"
    This one isn't really necessary but describes the content of the data.
  • "Content-length: 93"
    The http-server needs to know the length of the data that we're going to send.

The actual data
There should be a newline between the header and the data. The data should look something like this:

auth=fd1daaf6ad3cd5e574f158fc14346fd9&uptime=17126&load=0.12&idle=97&os=Linux&oslevel=2.2.13
The data consists of multiple 'key=value' pairs. All values should be url-encoded (so '@' should be '%40' etc.). Below are all possible keys described.
  • auth (required, 4.20)
    This is a 32-character key that is unique for each host. This key will be used instead of username+password+hid authentication (as used in version 4.00). The key for each host can be found on the hosts page.
  • uptime (required, 4.00)
    The value is the uptime in minutes of the host the client is running on.
  • load (4.00)
    The value should be something like "3.12" or "0.00", describing the actual load of the machine.
  • idle (4.00)
    This describes the percentage of the total uptime that the host was doing nothing. The value can vary from '0' to '100'.
  • os (4.00)
    You can send the Operating System along. This should be a string with at max 16 chars. It should be one of the values below. The OS-version is sent by using the key 'oslevel'.
    • AIX
    • BeOS
    • BSDi
    • Darwin
    • Embedded
    • FreeBSD
    • HPLaser
    • HPUX
    • IRIX
    • IRIX64
    • Linux
    • MacOS
    • NetBSD
    • Netware
    • OpenBSD
    • OpenVMS
    • QNX
    • RiscRouter
    • SunOS
    • TINI OS
    • Ultrix
    • Unixware
    • Windows
    (For additions, mail greatbotboy@noctumdesign.com)
  • oslevel (4.00)
    This key is only useful if you also send the key 'os'. It describes the version of the Operating System. Examples are "2.0.37", "NT", "4.11".
  • cpu (4.00)
    This key describes the cpu of the machine. You are advised, but not restricted, to use one of the following strings:
    • alpha
    • DS80C390
    • i386
    • i486
    • i586
    • i686
    • MIPS
    • pa-risc
    • ppc
    • sparc
    • sun4m
    • sun4c
    • sun4u
    • VAX
    (For additions, mail greatbotboy@noctumdesign.com)

Return values
If the HTTP request was ok, the uptime server will return a string in the form "UP4: xxx sss...". On succes, xxx is 000 and sss... is an optional message. If an error has occured, xxx will be the error code and sss... the error string

Faking
Now you know the protocol, it's easy to write a client that fakes the uptime. Personally, I think hosts running Linux 2.4.x with uptimes over 3 years are not cool. Maybe you think different.


Updated for uptimes.noctumdesign.com - 11/26/2001, greatbotboy@noctumdesign.com
Original protocol - 12/12/2000, tgm@uptimes.net

 

Copyright © 2010 Ryan Grove. All rights reserved.

Modified and Maintained by Robert Babel