Active servers tracker

by D.plomat on 07/12/2003 16:35, 38 messages, last message: 01/04/2004 18:28, 10457 views, last view: 05/05/2024 04:35

Hello every Cube fans. Many of us have already noticed, a difficult thing is making a dead server going with lots of ppl.
For that, i've developed a small KDE applet that tracks and display active servers on the taskbar. I'm now working on a Gnome version, and as it's free software, open-source and GPL'ed, maybe someone could re-use parts of my code to make a W32 version.
Further i may eventually make a qstat interface.
On those mirrors are:
-Screenshots
-Installation instructions
-Download link ;)

http://www.chez.com/dplomat/cube/
http://membres.lycos.fr/dplomat/cube/
http://dplomat.web1000.com/cube/

Any feedback welcome.

   Board Index   

#19: Re: A suggestion

by D.plomat on 07/16/2003 12:23, refers to #18

Maybe for a next version we could hope that the server stats protocol would be public. But, still using a masterserver is good for preserving game servers bandwidth, if it would cache the queries to limit the queries frequency for other servers, and if it would expose a more machine-friendly interface (ie tabbed text).

reply to this message

#20: Re: A suggestion

by Thalion on 07/16/2003 17:19, refers to #19

What's the difference? When you query the masterserver, doesn't it in turn query the game servers? And if it doesn't (but caches the result) - then you won't be able to tell when someone joins the server... anyhow, caching can be done on the client side as well (by the applet itself), but what's the point? It is supposed to give the _current_ status anyways!

reply to this message

#21: Re: A suggestion

by D.plomat on 07/16/2003 18:23, refers to #20

You're right. Actually the masterserver queries others each time, but the problem is that if say 60 person uses the applet (very unlikely now, but when there's gonna be a Gnome and a win version...), the masterserver, and each server would take 1 query per second. So if it used a cache algorythm to query others only if the last update is >30 sec, we can still have a better refresh rate, and Cube servers wouldn't take more than a query every 30 sec. The masterserver itself (or a cache i could host somewhere) would take more, but as it'd serve only static content on each query, it would reduce a lot server load.
ie: if a client applet already asked status 2 sec ago, it's overkill to re-query every Cube server now, we can send it the data we got from Cube servers 2 sec ago.
We talked about this with Kristian, and he said that eventually he would modify the masterserver web page to do this.

reply to this message

#22: Re: A suggestion

by D.plomat on 07/16/2003 18:27, refers to #21

That is, if it's for preserving the bandwidth, having the current status with a maximum worst-case latency of 30 sec, it's still acceptable, and if this reduces server load, we can maybe afford a better refresh rate, let's say real-time adaptation of the refresh rate depending on server load and bandwidth.

reply to this message

#23: Re: A suggestion

by Thalion on 07/16/2003 20:00, refers to #22

Ah. I see now. Sorry for being stupid =)

reply to this message

#24: Re: ..

by monsterc.00 on 07/30/2003 03:26, refers to #4

I've tried running this on KDE 3.1.1a, and the applet doesn't seem to work to well...

The applet display constantly flickers, and it knocks my cpu usage up to 99% (before running it, my cpu usage is usually around 1 or 2%).

It's a great idea though and it is sure useful when trying to find a match...

reply to this message

#25: Re: ..

by D.plomat on 07/30/2003 12:29, refers to #24

Only tested it with KDE 3.0
Will test with 3.1 as soon as i upgrade...

reply to this message

#26: Re: ..

by monsterc.01 on 10/22/2003 01:56, refers to #25

Did you ever upgrade? :)

reply to this message

#27: Re: ..

by D.plomat on 10/28/2003 18:47, refers to #26

Very often updated glibc, kernels, XFree, various daemons and tools, but not KDE, and i'm very busy now :(

reply to this message

#28: Re: ..

by D.plomat on 12/02/2003 00:13, refers to #24

Reproduced it on my shiny new Gentoo 1.4 / KDE 3.1.4

my CPU went to ~60% but that was still too much for my taste ;)

the setBackgroundColor raised a QPaintEvent recursvely... strange that it's only with KDE>=3.1

now fixed :)

the good new is that with a Gentoo you only need
./configure ; make ; make install
and it's working, bye bye rpm dependency hell :)

So:

reply to this message

#29: KDE applet version 1.3 released

by D.plomat on 12/02/2003 00:19

-fixed a bug that made it use much CPU load on KDE>=3.1
-display goes gray when there's a connexion error

As usual, any feedback/feature requests are welcome, even if it's just to say "it worked right out of the box" or "i got those error messages when compiling: <some_nasty_errors>" :)

reply to this message

#30: ..

by Pathegreat@hisFathers on 01/02/2004 19:24

D. , i want a win32 one, because i always wanted one.

reply to this message

#31: Re: ..

by hungerburg on 01/02/2004 19:37, refers to #30

how about cube servers supporting the gamespy protocol? so one wouldnt have to mess with the crypting of gameplay. and the eye and xqf support it, and masterserver output is easy to parse.

(I put a feature like this on the wishlist several times :) although I learned of gamespy protocol only recently.

reply to this message

#32: server to browser protocol

by hungerburg on 01/02/2004 20:23, refers to #31

documentation of the "gamespy" protocol is at
http://unreal.epicgames.com/IpServer.htm because, its actually an unreal thing. it is human readable. the /status/ query fetches everything a server browser needed to know. any coders?

reply to this message

#33: Re: ..

by Piglet on 01/03/2004 11:04, refers to #31

It is unlikely that the community as a whole (and possibly aard in particular) will accept this as a good idea.. Somehow it seems to go against the 'ethic' of cube.

reply to this message

#34: Re: ..

by hungerburg on 01/03/2004 13:34, refers to #33

I dont get that.

reply to this message

#35: Re: ..

by Piglet on 01/03/2004 23:44, refers to #34

In which case it's rather difficult to explain.. I of course may be wrong. However I think Aard has previously stated that he didn't want to use a 'commercial' server browser system (or turned one down or something, I cant remember the event exactly (sorry if I misremembered)).

reply to this message

#36: Re: server to browser protocol

by D.plomat on 01/03/2004 23:52, refers to #32

Unfortunately i'm very short on spare time, but if/when i'll be making a win version, as i already stated, i'll have to make some kind of results cache script (in PHP). I may eventually give it a try, like making some kind of 'protocol converter' which queries my PHP script and feeds game information to servers using gamespy protocol.

reply to this message

#37: Re: ..

by hungerburg on 01/04/2004 14:21, refers to #35

another reason coming to my mind is, that the encryption in aards builds is done in enet; indiscriminately on all packets sent and received.

my idea (the "gamespy protocol" one) of having another port sending the server info unfortunately is ignorant the fact, that serverinfo already has its own port and is encrypted nevertheless.

reply to this message

#38: Re: ..

by D.plomat on 01/04/2004 18:28, refers to #35

Well, i'll be pleased to make the game information the most widely available, so i'll have to make this PHP cache script to avoid using extra bandwidth on fov120.

The first purpose was only to make also a Gnome and a windows version of my applet, but if there are already other free softwares/sites/servers that offers the same services, i'll be happy to provide them with this information if they use standard and not too complex protocols.
But of course i won't bother developping nonstandard-protocol converters to give this information to commercial sites. However, if commercial sites want to have this information i think that's not a problem as long as it's also available to free softwares/services, so if they use standards protocols they'll have it.

I think that's compliant with Cube community's philosophy, but if Aard says that's not then i'll adapt my script.

I remember a post where Aard gives a list of games sites he gives information to, i don't know if this list is for practical or ethical reasons, but if Aard wants so i can easily restrict the availability of the info to those sites only.

reply to this message

   Board Index