| 1 |
root |
1.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 |
|
|
|
