[crossfire] new metaserver
Mitch Obrian
mikeeusaaa at yahoo.com
Sun Jun 5 11:41:50 CDT 2005
Cave's php metaservers are great. The sms's are sent
the data by the servers. They then send the info to
the cms which sends the info to the other sms's. This
way (since the sms's are trusted) the cms is unDoSable
as it's ip is unknown except for the trusted sms.
Since cave's metaservers are written in php they can
be hosted anywhere... including hosting companies with
near unlimited bandwidth.
We should implement it, it has been written. It is
good. The time for discussing how it should be done is
passed as we allready have a product now.
--- Mark Wedel <
mwedel at sonic.net
> wrote:
>
>
As asked, here is my thought on this.
>
>
To make typing this easier, CMS = chief (core)
>
metaserver. SMS = slave metaserver
>
>
There is one CMS. All crossfire servers that want
>
to be listed in metaserver
>
output send there data to this server (exactly how -
>
udp/tcp, and what to send
>
is an open issue. My thought is that the server
>
should send most every bit of
>
data the might be useful - after all, it's only
>
sending an update packet once a
>
minute or something, so the amount of bandwidth for
>
that is trivial). My
>
thought is also that this should be an actual daemon
>
like program - I think
>
having it be up holds some advantages. One being
>
that the connections from the
>
servers to it can be persistent (presuming tcp here)
>
- that makes things a lot
>
easier on the server side, and also replication
>
side. The only sites that can
>
request data from the CMS are trusted SMSs. The CMS
>
serves the data in a
>
relative raw format. The CMS would also provide
>
information on the SMS's, just
>
like the server (haven't got any requests from this
>
SMS for a while, etc). The
>
new CMS would need to be a bit more robust than what
>
is there now.
>
>
There are numerous SMS's. The clients talk to one
>
of the various SMSs. These
>
SMS's talk to the CMS to get their data. The ideal
>
case, IMO, would be for the
>
SMSs to also be persistent program, and thus could
>
just have a tcp connection to
>
the CMS. However, probably not any reason that the
>
CMS couldn't just to a
>
connection to SMS, get data, close connection. Thus
>
a php script could be
>
written to get this data. Probably a reasonable
>
idea for the SMS to at least
>
potentially be web based. Depending on the web
>
server and access a person has
>
to it, the way it gets data could vary.
>
>
For example, a php based one would just contact
>
the CMS periodically (not
>
necessarily every time it gets a requests -
>
presumable it should have a cache
>
file it uses - if the cache file is too old, then it
>
gets new data from the server).
>
>
For other people, that can actually run scripts on
>
the web server, they can
>
perhaps have a persistent script that is in contact
>
with the CMS, and just gets
>
the data and stores it as static pages.
>
>
The client would ship with a file that lists the
>
current SMS's as web
>
addresses (given different people host them, you
>
can't just have a URL like
>
http://myhost/cfservers
- people may need to do
>
things like
>
http://myhost/~username/cfservers
or whatever).
>
>
The SMS would have two bits of data from the CMS -
>
the list of all the servers
>
and their stats, which has obvious usefulness.
>
However, it would also have a
>
list of the other SMSs, so that the client can
>
update its lists of what SMS's
>
are out there. Thus, as long as a client can find
>
one SMS, it can talk to it,
>
and now get an updated list of all the new SMS.
>
Thus, as SMSs come and go, the
>
client will automatically keep up to date and not
>
have to rely on some other
>
external site.
>
>
If the CMS is down, the SMS's just serve the last
>
data they have. This data
>
will eventually become stale, but with very limited
>
traffic going to the CMS, I
>
think DOS attacks against the CMS are much less
>
likely.
>
>
A few other notes:
>
>
An agreement/usage policy for people that want to be
>
SMSs is probably in order.
>
Probably the main bit of that policy is that it
>
won't abuse the CMS (eg,
>
behave correctly), but also that it has to serve the
>
data it gets from the CMS
>
in basically an unaltered state (can't drop servers
>
it doesn't like, can't
>
add/fake servers it does like, etc).
>
>
Also, relative to the client getting the data, it
>
should be served up in a raw
>
form (eg, not html, but something easy to parse).
>
That said, the CMS can also
>
make html output if it so desires, but that would be
>
for human readable format,
>
not for the clients.
>
>
I think this takes various bits people have
>
discussed but with some changes.
>
>
>
_______________________________________________
>
crossfire mailing list
>
crossfire at metalforge.org
>
http://mailman.metalforge.org/mailman/listinfo/crossfire
>
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
More information about the crossfire
mailing list