115 lines
4.5 KiB
Plaintext
115 lines
4.5 KiB
Plaintext
[This document is partly out-of-date; it was updated by reverse engineering the
|
|
client code accessing the metaserver. It therefore describes the as-is state
|
|
rather than what was intended. Communication between server and metaserver was
|
|
not updated; this information may not reflect the current implementation.]
|
|
|
|
|
|
This brief document is meant to describe the operation of the crossfire
|
|
metaserver, as well as the form of the data.
|
|
|
|
The metaserver listens on port 80 for tcp and on port 13326 for udp packets.
|
|
|
|
The server sends updates to the metaserver via udp. The metaserver only
|
|
does basic checking on the data that server sends. It trusts the server
|
|
for the ip name it provides. The metaserver does add the ip address
|
|
and also tracks the idle time (time since last packet received).
|
|
|
|
The client gets its information from the metaserver through connecting by means
|
|
of tcp. The client should retrieve
|
|
http://crossfire.real-time.com/metaserver2/meta_client.php and parse the
|
|
response body if successful; the body's content type is text/plain.
|
|
|
|
The current metaserver implementation is in Perl. But the metaserver could be
|
|
in any language. Currently, perl is fast enough for the amount of data
|
|
that is being exchanged.
|
|
|
|
The response includes zero or more server entries. Each entry begins with the
|
|
line "START_SERVER_DATA" and ends with the line "END_SERVER_DATA". Between
|
|
these lines key-value pairs ("key=value") may be present.
|
|
|
|
The entries are sent in arbitrary order. A client should apply some ordering
|
|
when displaying the entries to the user.
|
|
|
|
TODO: is there any ordering of key-value pairs?
|
|
|
|
TODO: which fields are mandatory? which are optional? what are default values
|
|
for optional fields? how should the client behave if an unexpected field is
|
|
present? how should if behave if a critical field (hostname) is missing?
|
|
|
|
TODO: how should the client behave in case of syntax errors? a) incorrect
|
|
key-value pair syntax; b) additional information outside
|
|
BEGIN_SERVER_DATA..END_SERVER_DATA?
|
|
|
|
TODO: are duplicate key fields allowed? how should the client behave if
|
|
duplicates are present?
|
|
|
|
TODO: The current gtk clients accept lines "START_SERVER_DATA=value" and
|
|
"END_SERVER_DATA=value" as well. This is probably not intentional since the
|
|
metaserver does not send such lines and since the client ignores the value
|
|
present.
|
|
|
|
TODO: How are newline characters encoded in the comment field?
|
|
|
|
The following key values are used:
|
|
|
|
- hostname: The hostname of the server. It is the host the client should
|
|
connect to.
|
|
|
|
- port: The port of the server. It is the port the client should connect to.
|
|
|
|
- html_comment, text_comment: A comment describing the server in either HTML or
|
|
plain text. It can contain most any character or data. It is used by clients
|
|
to describe the server to the user.
|
|
|
|
TODO: recommended maximum size that clients should be able to display
|
|
correctly
|
|
|
|
- archbase, mapbase, codebase: The archetypes, maps, and server code the server
|
|
uses.
|
|
|
|
TODO: specify allowed/recommended values; currently either "Standard" or
|
|
<version> is used for information as present in SVN; non-standard information
|
|
is not specified.
|
|
|
|
- num_players: The number of players currently on the server.
|
|
|
|
TODO: does it include WIZ players? does it include BOTs?
|
|
|
|
- in_bytes, out_bytes: The number of bytes the server has taken in or written
|
|
out over the socket over the lifetime of that server instance.
|
|
|
|
- uptime: The number of seconds this server instance has been up. When
|
|
referring to server instance for the in_bytes, out_bytes, or uptime fields,
|
|
this means how long since the executable has been started. A particular host
|
|
may have been running a server for quite a long time, but due to updates or
|
|
crashes, the length of time the server instance has been up may be much
|
|
shorter.
|
|
|
|
- version: The version of the server.
|
|
|
|
- sc_version, cs_version: The protocol version the server supports.
|
|
|
|
- last_update: The timestamp (seconds since 1970-01-01 00:00:00) at which the
|
|
metaserver last received and update from this server.
|
|
|
|
|
|
An example of an entry from metaserver output:
|
|
|
|
START_SERVER_DATA
|
|
hostname=crossfire.metalforge.net
|
|
port=13327
|
|
html_comment=Latest SVN 1.x branch.<br>Eden Prairie, MN US<br>4.65Mb link<br><a href="http://crossfire.real-time.com">crossfire.real-time.com</a>
|
|
text_comment=Latest SVN 1.x branch, Eden Prairie, MN US
|
|
archbase=Standard
|
|
mapbase=Standard
|
|
codebase=Standard
|
|
num_players=3
|
|
in_bytes=142050710
|
|
out_bytes=-1550812829
|
|
uptime=909914
|
|
version=1.11.0
|
|
sc_version=1027
|
|
cs_version=1023
|
|
last_update=1214541369
|
|
END_SERVER_DATA
|