[crossfire] new metaserver
Mark Wedel
mwedel at sonic.net
Sat May 28 01:45:44 CDT 2005
Brendan Lally wrote:
>>>>
mwedel at sonic.net
05/27/05 07:08 AM >>>
>>
>>
IS the idea to have DNS records for metaserver.crossfire.org (or whatever)
>>
point to all those possible/trusted meta servers?
>
>
>
There are two lists, the game server list and the metaserver list.
>
>
Each metaserver has a copy of both lists, that they sync with the
>
metametaserver.
>
>
when a client connects, they have their own list of metaservers (that will be
>
install with the tarball) and they pick randomly a metaserver from that
>
list. From that metaserver they get a list of servers, and a list of
>
metaservers. In future they use that new list to pick randomly from.
I'd think that the client having too muched cache information can lead to its
own problem. For example, if one of the metaservers goes away, that then leads
to cases of when the client uses that metaserver, it could take a while for that
connection attempt to time out.
This really gets to be a problem when you see that there are still some pretty
old clients in use out there (somewhat caused by variosu distributions having
old client versions).
so this list of metaserver should be ones that are really trusted or known
that they will be sitting around for a long time.
>
Yes, once you have a metaserver running, you would email the metametaserver
>
admin, and say 'hello, I have a new [active/passive] metaserver it can be
>
accessed as [ip adress or hostname] and updates via [ip adress or hostname]
>
(those may or may not be the same.
>
>
the list of metaservers would then be appended to include your metaserver,
>
and the ip adress you use for updates would be let through the firewall
>
around the metametaserver.
>
>
This assumes that we trust you :)
this does add a layer of administration that does not currently exist. At
least for the metaservers, probably not that big an option, because this list
probably doesn't change very much. However, probably need to set up a pretty
solid policy for what metaserver will be added and what won't be - adding a
metaserver to the client and servers as one to use that then goes away causes
some problems.
>
>
>>
It seems to me that it would also be a better idea not to have a
>>
'metametaserver' at all - just go peer to peer, with the active metaservers
>>
periodically sending the data to one of the other metaservers (once a
>>
minute or something, it could connect to another, the two exchange
>>
information, merging any duplicates/keeping the later). This removes the
>>
single point of failure if the metametaserver fails for some reason, at the
>>
expense of the data being not quite up to date.
>
>
>
I considered this, but I couldn't see a nice way to add new metaservers
>
securely (bearing in mind that without some form of checking, a hostile
>
server could crapflood the other servers into uselessness). All methods that
>
were sane to implement would use a central auth server anyway. If that is the
>
case, then you might as well connect to it to send the data too, since it is
>
going to be there anyway.
Well, your already constructing a list of trusted metaservers to be
maintained. In a peer to peer situation, it'd only take data from one of those
other trusted metaservers. It really isn't much different than your
metametaserver setup, but also ends up distributing the administration of that
point.
It also really doesn't change security at all. Right now, in your setup, if
one of the trusted metaservers really isn't secure, it could send all sorts of
bogus data about servers to the metametaserver.
>
>
If there is a way around this that I haven't considered, then let me know.
>
>
It also may increase traffic quite substantially compared to a system where
>
each server expects to have ~ (number of hits old metaserver had on average
>
)*2/number of metaservers + some updates sent out to the metametaserver.
Traffic analysis on this would be what I consider 'odd'. Each metaserver in
the p2p setup would exchange all the info it has. Thus, you would get something
like A & B exchanging info (and thus at that instance, having exactly the same
data). B & C then exchange data - at this moment, both B & C are perfectly in
sync, and include the data from A. At some point, A talks to one of those
servers (not important which ones) and gets all synced up again.
If B goes away, A & C can still happily exchange info and keep up to date.
The only real magic in all of this is how often the metaservers should exchange
data. It also means that data may not be quite as up to date.
Probably makes most sense for each metaserver to randomize the order of its
lists of other known metaservers, but then just go in a simple round robin -
that way, every server should remain pretty up to date.
>
>
>
Yeah, it'd use TCP, it has to to connect to a webserver I'm toying with the
>
idea of using libcurl directly to handle most of it, this is fairly quick and
>
easy, compared to implementing HTTP manually, but it does add a new
>
dependancy (albeit a common one). The alternitive is to write directly to the
>
socket.
>
>
But certainly for the server starting up and forking to have the metaserver
>
be contacted should be fine, it would just then travel randomly down the list
>
of metaservers until it finds one that returns a 200.
>
>
It should be quite easy to have a lock file setup to ensure that the
>
metaserver requests don't overlap..
The problem is you basically need to fork each time you connect to a
metaserver to send it data. Right now, the server sends data every minute. I'm
not sure the cost of the forks, but I know that due to memory leaks, the server
image itself can become quite large.
One thought I have is that the most like time to block is the initial lookup
and connection. If the server can use the same connection, it could set the
socket to non blocking, and this is then no longer a problem.
However, I'm not sure if that will work with php based web scripts (I think
the connection will be closed after each update).
>
>
>>
Version should be included in the top line, not the comment line, as it is
>>
now
>
>
>
The point of the bottom line is that it is what the player 'sees', it isn't
>
needed for the client to connect to know what release the server is running.
>
A player however, will want to know which version the server runs, so it will
>
go on the bottom line, as player-known information.
Note that right now, for space reason, the comment (player section you
describe) isn't even displayed.
Also, I personally think it'd be much easier/nicer to be able to display
version and number of current players in nice tabs, and that requires them being
contained as seperate fields - otherwise, the client has to try pulling that
data from the comment field.
>
>
If the protocol changes, such that it breaks against older or newer clients,
>
then the client will be able to compare the protocol entry and simply not
>
show those that are of the wrong version.
You're over analzying the problem. The protocol versions are there to avoid
this problem - there shouldn't be problem with mistmached protocol versions -
the design is such that propely written clients and servers won't send data to
the other end that isn't supported by the protocol version at the other end.
This can mean that in some cases, the client can't use the newest features (but
wouldn't have the code for it anyways). It also does complicate things a
little, because checks in the code are added for cases of protocol versions.
That said, occasionally, there can be times where changes basically resuilt in
clients not working - the only really case I can think of was the 'big image'
support. However, there wasn't a clear point on this (the protocol was updated
to handle it before images actually started to get merged, so there was an
overlap where the old clients would work, until images started to get merged).
But hte problem is that if there is a protocol mismatch, the client won't be
able to know what to do about it. If the client version is later than the
server, no problems - it can handle whatever the server throws at it, and will
fallback to the older commands to send to the server.
If the server is later than the client, the client can't have any idea how
minor or major those changes are, and thus can't know if it will be able to
properly talk to that server (once connected to the server, the server will
examine the numbers, and can potentially know if there is a conflict)
>
This information is also acquired by the metaserver, it connects back to the
>
ip and port it was given, and checks that the banner says 'crossfire' in it.
That of course complicates things, because that operation can now block also.
>
>>
Note you should look at the current metaserver for what data it sends. For
>>
example, it also sends along the number of input and output bytes it has
>>
sent (useful for some scripts that collect that stuff) as well as how long
>>
the server has been up.
>
>
>
Do any scripts actually collect that? I can't say I've noticed it being used,
>
if it is wanted though, it can be added easily now. (adding it later, is more
>
interesting....)
At one point, I think mids had script/data on his website that showed that data.
The most important one is probably the number of players (and version) on the
server - I think variosu people do look at the info when determining what server
to play on.
More information about the crossfire
mailing list