Active servers tracker

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

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   

#4: ..

by Pathegreat on 07/13/2003 00:09

thats realy cool d, i think for a hardcore cube fan that would be perfect aka me

reply to this message

#5: Re: ..

by Thalion on 07/13/2003 09:42, refers to #4

It's for Linux =)

reply to this message

#6: Re: ..

by D.plomat on 07/13/2003 11:33, refers to #3

Well, i don't know how CTF handles masterserver, if it uses the same masterserver... i'll take a look at it when i've some time.

reply to this message

#7: Re: ..

by D.plomat on 07/13/2003 11:42, refers to #5

...As all my personal developments :)
I "liberated" all my personnals systems from windows approx 6 month ago. (except this old P150 Libretto i'm on now -I still manage to get decent fps on it... in a 80x60 window =) -)
Visual C++ or Delphi wouldn't be very comfortable on it, and i'm enough bored of windows devel at work ;)
But as the code is trivial to understand, it would be very easy for someone to make a windows version.

reply to this message

#8: Re: ..

by pushplay on 07/13/2003 12:14, refers to #7

If that someone knew the proper api. I don't.

reply to this message

#9: Re: ..

by D.plomat on 07/13/2003 15:35, refers to #8

In fact it is possible to re-use the servdesc struct, the ServParse, ActiveServers, SortServers and ShortMode functions in a new MSVC++ project, the win32 APIs that needs to be known are:
-Network transparency, or at least some http get function
-Taskbar notification area (i knew this one 5 years ago, but don't remember at all, will eventually take a look on a book.)
-Timer
When i've finished the Gnome version and all things in my todo list (obviously a whole bunch ;) , i may eventually give it a try, but that's very unlikely.

reply to this message

#10: Re: ..

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

I don't promise it, but I'll take a look. My WinAPI knowledge is still better than my Unix programming skills =)

reply to this message

#11: um

by Aardappel on 07/15/2003 09:49

cool idea, but I think querying the masterserver every minute is a bit overkill, wasting bandwidth. Better to do it every 10 minutes, and have a way to query explicitly if you fancy a game.

reply to this message

#12: Re: um

by D.plomat on 07/15/2003 14:48, refers to #11

Well, at the beginning i didn't knew what refresh rate i could afford, i used 20 sec for my development version. Finally Kristian Duske told me to use 1 min. He also explained me some details about the masterserver page that i didn't knew.
Off course i'll follow exactly what he tells me for preserving the bandwidth.
Now i'm thinking of hosting somewhere a server that periodically caches masterserver queries so that those applets don't use bandwith on fov120 and still keep a good refresh rate. I should have cc'd you on Kristian mail, so i'll transfer it now.

reply to this message

#13: Re: oops

by D.plomat on 07/15/2003 15:53, refers to #12

Looks like fov120.com's MX refuses incoming mails from yahoo.fr... i'll try to send them using another account later..

reply to this message

#14: A suggestion

by Thalion on 07/15/2003 16:02

I see you parse HTML... maybe it would be simplier to use this?

http://wouter.fov120.com/cube/masterserver/retrieve.do?item=list

reply to this message

#15: Re: A suggestion

by D.plomat on 07/15/2003 16:14, refers to #14

The format is very cool, very bandwidth-friendly, but it only points to servers, so i'd have to query each one and that would be very bad for their bandwidth. Moreover it would require knowledge of the official Cube servers protocol, that would be much more coding for me ;) and having official Cube protocol in very small applets would make it way easier to disassemble, plus i couldn't distribute it under GPL.
Already talked about this with Kristian, the ideal thing would be an intermediate between those 2 formats, let's say a pure tabbed text containing all informations that are on the web masterserver page.

reply to this message

#16: Re: Still agree that

by D.plomat on 07/15/2003 16:16, refers to #15

parsing HTML is not the most elegant solution, and very sensible to layout changes on the page :(

reply to this message

#17: Re: A suggestion

by Thalion on 07/15/2003 17:51, refers to #15

Maybe it's just me, but is the protocol for getting server stats also kept secret? I think I managed to get server info somehow, once...

reply to this message

#18: Re: A suggestion

by hungerburg on 07/16/2003 01:40, refers to #17

Cube compresses all data on the network, which is already a sort of unbreakable encryption to me, though the code is in the open. (i'm with http most of the time.) but it might be a oneliner in perl to get the clear text.

aards binary sends different bytes than the ones compiled from source. so I guess you had a hard time. its quite easy to get stats from a battleforce server and people building huge sites around those, why should cube differ?

reply to this message

#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

   Board Index