Location in Lat/Lon/Height (type double)
LLH values must be in the range -360.0 <= (L1,L2) <= 360.0

To describe a polygon, provide the Latitude and Longitude of the polygon's points. For example,suppose we have three point polygon ((lat1,lon1),(lat2,lon2),(lat3,lon3)), which is located at the height of h.

To enter it into wherehoo, the command is:
LLH lat1 lon1 h lat2 lon2 h lat3 lon3 h

The current system supports 2-dimensional spaces only, so the height provided with each point must be the same.

Return records that were alive on or after this offset from NOW (NOW is calculated at the moment the query is run). If specifying BEG in a query, always use END as well or results may be confusing. Offsets may be positive or negative.

If BEG and END are not specified (they should be used only when really necessary) the records returned are those that are alive at the moment the query is run, that is, "now"

Return records that were alive on or before this offset from NOW (NOW is calculated at the moment the query is run). If specifying END in a query, always use BEG as well. Offsets may be positive or negative.

If BEG and END are not specified (they should be used only when really necessary) the records returned are those that are alive at the moment the query is run, that is, "now"

Heading for directionally-focused searches (0.0 <= heading <= 360.0, type double). Default is 0°=due North.

As of version 0.70, LIM is not compatible with a directional search. Do not use LIM and HDG together.

Limit maximum number of records returned (type integer). limit must be >= 0.
If limit = 0 (the default) there is no limit and all records are found and returned.
This command is provided so that clients can help the server do less work, by limiting the number of records retrieved i the background SQL query.

As of version 0.70, LIM is not compatible with a directional search. Do not use LIM and HDG together.

Return only records whose header indicates they are exactly this MIME type (full-string match is performed)
If the thing pointed to by this record is another Wherehoo server, the MIME type will be 'application/x-whserver'
If this parameter is sent, only exact matches to mimetype will be returned.
If this parameter is not sent with the query, records with all mime types are returned.

Return only records whose protocol is exactly protocol
If the bits in this record's DATA field are the thing pointed to (DATA is not the URI of some location, but IS the data for that place - a binary block, some words, some music, some code, whatever), then the protocol is 'WHEREHOO'

If this parameter is not sent with the query, records with all protocols are returned

The table of protocols is maintained manually.
Please bring missing or new protocols to the attention of Wherehoo project leads.
Permitted protocols are listed at http://wherehoo.media.mit.edu/about/supported-protocols.php

Here comes the binary data.

The client should send:
DAT data_size
to tell the server the data's coming, then a CRLF (like all other commands), then...
data_size bytes of data
followed immediately by
the 20-byte SHA-1 signature, created using the data plus the client's secret (arranged in advance)

Here is a class that holds the data block and provides method SHAhash(mysecret) to return the SHA-1 signature:

import java.security.*;
public class dataBlock {
public byte[] data;


public byte[] SHAhash(String mysecret) {
byte[] mdfinal;
try {
MessageDigest md = MessageDigest.getInstance("SHA-1");
md.update(data); // the data and...
md.update(mysecret.getBytes()); // my secret
mdfinal = md.digest(); // yield the secure hash
} catch (NoSuchAlgorithmException nsae) { return null; }
return mdfinal;
}
}

The total bytes your client sends must be exactly data_size + 20
1 <= Data_size <= max_data (max_data is stated by the server in response to the client's IDT)
If data_size is greater than max_data, then only the first max_data + 20 bytes will be read and the client will be disconnected as the server tries to interpret the additional data as commands. So, don't do that.

Immediately after sending the 'DAT data_size' line, send your bytes of data plus the 20-byte signature, all as one contiguous binary block. Then go back to line-reading and watch for "ACK". The server will answer with an ACK after it's received your data_size bytes plus the 20-byte signature.
If there's something wrong with your data stream, or if data_size is < 1, the server will return a NAK and break its connection.

WHERE DO I GET AN IDENTITY AND SECRET SO I CAN ADD RECORDS?
For now, we give them to testers after manually adding the IDT and signature pair to the server's user database. Please write to request one. Eventually, they'll be generated and exchanged with clients automatically.

Text metadata describing the thing pointed to by this record.
The length of the metadata should be <= the max_meta value provided by the server in response to the client's IDT.
If the metadata block is longer than max_meta, it will be truncated to the first max_meta characters.

MIME type of the data pointed to by (or contained in) this record.
For maximum happiness, use well-known MIME types.
If the thing pointed to by this record is another Wherehoo server, the MIME type should be 'application/x-whserver'

NOTE: Beginning with version 0.630, 11-1-00, MIME types are no longer validated against a list. We still recommend using well-known MIME types (else nobody will be able to use your records)!

The protocol an agent will use to retrieve the thing pointed to by this record.
For maximum happiness, use standard protocols. These are checked against a table built from ftp://ftp.iana.org/in-notes/iana/assignments/service-names. If the protocol is not found, Wherehoo will not insert the record.
The additional protocol 'WHEREHOO' is also accepted.
If the bits in this record's DATA field are the thing pointed to (DATA is not the URI of some location, but IS the data for that place - a binary block, some words, some music, some code, whatever), then the protocol is 'WHEREHOO'
The table of protocols is maintained manually. Please bring missing or new protocols to the attention of Wherehoo project leads.
Permitted protocols are listed at http://wherehoo.media.mit.edu/about/supported-protocols.php

No-op to forestall rx timeout by server if your client is running slowly or to see if server is still listening
Server answers with ACK if it's still listening

Server's response to an IDT from the client. All fields are variable length, space-delimited
example: wherehoo_server 0.480 30 20 1024 65535

wherehoo_server is a constant text string
version is the version number
timeout is the data timeout in seconds. Silence from client for this duration drops connection
min_expiration is the minimum number of seconds "later than the beginning time" that a record may end... This is to avoid thrashing the database with too-short-lived records
max_meta is the maximum length of the text metadata describing the contents of a Wherehoo record's data field
max_data is the maximum number of bytes of binary data that may be stored inside a Wherehoo record's data field

In response to a query from the client, the server sends back individual records.

1. A line of text containing descriptive data about the record's content is sent to the client
2. The client should check the descriptive data for compatibility ("can I actually handle this data type? protocol? data size?")
3. The client issues one of these instructions on a line by itself:

DATA if it wants the data (binary; byte count was stated in bytes field of record header - see below)
META if it wants the text metadata describing the contents of DATA (one line, size limit of max_meta)
SKIP to move to the next record
BYE to close the connection.

4. If the client sent "DATA" or "META" the requested stuff is sent. If the client asks for META and there isn't any (should have read the record header!) an empty line will be sent.
5. If client sent META, the server loops to #3, waiting for another command regarding this record (because the client might want DATA next).
... otherwise the server returns to #1 and sends descriptive data for the next record, or EOD (".") if there are no more records.

Record descriptive data appears on one line, space-delimited, in this format:
bearing compassdirection distance ttl bytes protocol mimetype meta

Removed checking of MIME type presented with the MIM command
If MIM or PRO are set (or both) when performing a query, the server will return only thos records that exactly match the provided MIME type and/or protocol.
Example:

ACT QUERY
LLH 42.361 -071.088 0
RAD 10000
MIM text/html
PRO http
.

This query only returns records that point to web pages accessible via the HTTP protocol