[crossfire] new metaserver
Mitch Obrian
mikeeusaaa at yahoo.com
Sun Jun 19 21:57:07 CDT 2005
Most webservers out there are linux. This isn't a
problem IMO.
--- Mark Wedel <
mwedel at sonic.net
> wrote:
>
Brendan Lally wrote:
>
>
>> Right - I'm not sure the cost of doing it web
>
server based vs independent
>
>>program. For the number of crossfire servers
>
we're talking about, probably
>
>>not a big deal in any case - although with it
>
being web server based, you
>
>>do have to be concerned with things like file
>
locking, which may not scale
>
>>will with large number of updates happening - this
>
is mostly because it has
>
>>to do all updates through a file. A standalone
>
metaserver has the
>
>>advantage it only has to do some locking on the
>
data structures, and only
>
>>periodically needs to write it out to a few (say
>
every few minutes for
>
>>backup purposes). The php one has to read/write
>
the file every time in
>
>>gets an update. As said, for the number of
>
servers we have, may not be a
>
>>big dea.
>
>
>
>
>
> Yes, I don't know how to get round this, although
>
at least on a good
>
> webserver, if the files are accessed enough to
>
matter, they shouldn't be
>
> leaving RAM.
>
>
True, but that is harder to predict. The OS will
>
do the file caching, but if
>
the webserver is busy enough, the cache hit rate
>
might be poor. The flip side
>
is that if the metaserver is used a lot, more likely
>
that the file will be
>
cached, and thus performance improves.
>
>
But how the OS caches varies OS to OS. Linux is
>
very aggressive on caching
>
data, others less so.
>
>
OTOH, if the core metaserver can be run as a non
>
web program, I think there
>
are still benefits from doing that. It's a little
>
more work to write such a
>
program, but probably not much.
>
>
Related to this, how do the slave metaservers do
>
updates? They can obviously
>
only do anything when someone is requesting data
>
from them. Do they look at
>
their local cache modification time, and if it
>
hasn't been updated in X minutes,
>
go talk to the core metaserver to get up to date
>
information?
>
>
>
>
>
>> In my ideal world, the metaservers should be
>
able to provide information
>
>>in both 'pretty' html and something raw. One
>
could envision this by
>
>>something like:
>
>>
>
>>
http://myhost/metaserver.php
>
>> giving nice html output, and something like:
>
>>
>
>>
http://myhost/metaserver.php?output=raw
>
>>
>
>
>
>
>
> or indeed, showservers.php and
>
showserversclient.php, which were two of the
>
> first things that I wrote when I started to play
>
with this. (since a
>
> webbrowser is easier to play with than some
>
quickly crufted C code.)
>
>
>
> I haven't done file locking there because I am yet
>
to get round to it.
>
>
>
> You could have a get call and merge the two I
>
guess.
>
>
Probably not a big difference for them to be one
>
program. Two seperate
>
scripts work just fine.
>
>
>
>>>watchdog when it is compiled in has the server
>
send UDP packets to a
>
>>>local socket. AFAICT it doesn't really matter to
>
much /what/ it sends, so
>
>>>it might as well send the data that the
>
metaserver will use, in that case
>
>>>then the program you describe would end up
>
looking similar to
>
>>>crossfire/utils/crossfire-loop.c (though maybe in
>
perl?)
>
>>
>
>> IMO, the metaserver notification helper has to
>
be started automatically
>
>>by the server, and not be an external entity
>
started via script (like the
>
>>watchdog one uses). This is simply easy of use -
>
otherwise the problem is
>
>>that someone starts it by hand, or uses their own
>
monitoring script and
>
>>don't send metaserver updates when they should.
>
>
>
>
>
> True, but a fork and exec at startup can do that.
>
>
Right, but that then isn't really the watchdog
>
program.
>
>
>
>> Also, it is probably nice for the metaserver
>
updater to be connected via
>
>>tcp or pipe to the server, so each can know when
>
the other dies. If the
>
>>helper sees the server dies, it can send a last
>
update to the metaserver
>
>>informing it that the server just died, and then
>
exit. If the server sees
>
>>the helper dies for any reason, it can start up
>
another copy. The problem
>
>>with the udp notification and watchdog is that the
>
watchdog could be dead
>
>>and server would never know.
>
>
>
>
>
> This is true, although to a certain extent the
>
idea is that the watchdog is
>
> simple enough to not die.
>
>
Famous last words. But there are of course other
>
possiblities beyond the
>
watchdog having faults. Someone accidentally kills
>
it. Something external to
>
it causes it to fail (out of memory, disk error,
>
whatever). And right now, if
>
the watchdog does die, not a big deal - server
>
continues to run, no one notices
>
anything different. However, if the metaserver
>
helper dies and is not noticed,
>
then the server in question is no longer reported,
>
which does cause problems
>
>
I'd personally like things to be simpler - if a
>
user can just run the main
>
server, and everything works, that is much better
>
them then having to restart
>
the helper manually.
>
>
>
>
>
>
>> The helper program also needs to have some basic
>
security - making sure
>
>>the connection is coming from the local host and
>
not something remote
>
>>(don't want some remote host connecting to the
>
helper and forging
>
>>information).
>
>
>
>
>
> Is it insecure at the moment? It /is/ already in
>
the server code, this was why
>
> I suggested using it, if it is there presumably it
>
at least works in some
>
> fashion (although this has been shown to be false
>
in the past).
>
>
Right now, it appears insecure, in that a udp
>
packet to port 13325 resets the
>
watchdog timeout. The code does not appear to do
>
any validation that the packet
>
in fact came from the local host.
>
>
the other problem is that it does use udp. While
>
spoofing IP here probably
>
isn't much a concern, it does mean that it is now
>
very difficult for the server
>
to know if that packet has been received, and thus
>
if the helper is still alive.
>
>
The other gotcha is that the main purpose of the
>
watchdog program is to
>
restart the server if it dies or is not responsive.
>
>
The main perhaps of the metaserver helper program
>
is to send data to the
>
metaserver. I can envision cases where this helper
>
could basically freeze up
>
resolving IP addresses and trying to connect to them
>
- in this case, this helper
>
really can't be doing anything else, such as
>
restarting the server if it
>
crashes. IMO, much better for this to be a
>
standalone
=== message truncated ===
__________________________________
Do you Yahoo!?
Yahoo! Mail - You care about security. So do we.
http://promotions.yahoo.com/new_mail
More information about the crossfire
mailing list