| 1 |
This brief document is meant to describe the operation of the crossfire |
| 2 |
metaserver, as well as the form of the data. |
| 3 |
|
| 4 |
The metaserver listens on port 13326 for both tcp and udp packets. |
| 5 |
|
| 6 |
The server sends updates to the metaserver via udp. The metaserver only |
| 7 |
does basic checking on the data that server sends. It trusts the server |
| 8 |
for the ip name it provides. The metaserver does add the ip address |
| 9 |
and also tracks the idle time (time since last packet received). |
| 10 |
|
| 11 |
The client gets its information from the metaserver through connecting by |
| 12 |
means of tcp. When the metaserver accepts the tcp connection, it dumps |
| 13 |
the metaserver information over the connection - there is no negotiation |
| 14 |
that needs to be done (and in fact, a telnet to port 13326 will show |
| 15 |
the dumped data). |
| 16 |
|
| 17 |
The current metaserver implementation is in Perl. But the metaserver could be |
| 18 |
in any language. Currently, perl is fast enough for the amount of data |
| 19 |
that is being exchanged. |
| 20 |
|
| 21 |
An example of a line from metaserver output: |
| 22 |
|
| 23 |
165.227.59.56|330|tavern.santa-clara.ca.us|0|1.0.0|Development server - |
| 24 |
usually running CVS or even later experimental code. At end of DSL link (128k |
| 25 |
upload). May be restarted unexpectedly - play at your own |
| 26 |
risk.|3254|117133|1569 |
| 27 |
|
| 28 |
For input and output, all this data is on a single line. It is broken up here |
| 29 |
to be more readable. |
| 30 |
|
| 31 |
The first field (165.227.59.56) is the ip address that send this to the |
| 32 |
server. The metaserver adds this information. |
| 33 |
|
| 34 |
The second field (330) is the number of seconds since the metaserver last |
| 35 |
received and update from this server. |
| 36 |
|
| 37 |
The third fields and beyond are all data the server has sent to the |
| 38 |
metaserver. |
| 39 |
|
| 40 |
The third field (tavern.santa-clara.ca.us) is the hostname of the server. |
| 41 |
This is provided by the server itself - the metaserver does not look |
| 42 |
this up. |
| 43 |
|
| 44 |
Fourth field (0) is the number of players currently on the server. |
| 45 |
|
| 46 |
Fifth field (1.0.0) is the version of the server. |
| 47 |
|
| 48 |
Sixth field (Development server ....) is comment. It can contain most |
| 49 |
any character or data. For clarity reasons, this is not used in the unix |
| 50 |
clients, but is used on the web page output. This should not contain any |
| 51 |
vertical bars, as it will then confusion programs parsing the data. |
| 52 |
|
| 53 |
Seventh field (3254) is the number of bytes the server has taken in over the |
| 54 |
socket over the lifetime of that server instance. |
| 55 |
|
| 56 |
Eigth field (117133) is the number of bytes the server has written out |
| 57 |
on the socket over the lifetime of that server instance. |
| 58 |
|
| 59 |
Ninth field (1569) is the number of seconds this server instance has been up. |
| 60 |
When referring to server instance for the 7->9'th field, this means how |
| 61 |
long since the executable has been started. A particular host may have |
| 62 |
been running a server for quite a long time, but due to updates or crashes, |
| 63 |
the length of time the server instance has been up may be much shorter. |
| 64 |
|
