PDA

View Full Version : HCE HaloRank.com



Sean Aero
April 1st, 2013, 05:04 AM
It's 2nd day of Easter and 1st of April a perfect day for a release I would say.

A lot has happened, but long story short.
The website is "finally" online and ready to be used.

What is HaloRank?
HaloRank is a website which keeps track of your HaloPC and HaloCE multi-player statistics. While at the same time providing additional fun, through achievements, challenges and best of all ranks!

How does it work?
Basically it uses a server application which tracks your score and send it to the HaloRank database. The database processes all the scores submitted and turn the scores into interesting and "usefull" stuff.

I'm a server admin what Server application will I need?
Currently the system only support Gandanur. Not the most popular app today, but it was a choice made way back.
Download Gandanur 13.3.0 for Halo here: http://www.gandanur.com/p/downloads.html

So how fast is this tracking mechanism?
Currently scores are processed within 15~30 seconds of an event happening.

I'm use a shared key/pirated the game or "HaloCE portable" (v1.00/v1.06) user, will my score be tracked?
Your score will be tracked but since this system is based on hash it will be quite hard to keep tracking your progress over time.
If you want to be tracked perfectly within in the system you'll need a legit install of Halo and a legit key. Measurements have been installed to filter out pirates hashes over time, however it can never be 100% perfect. This does not mean you can not play as a pirate, it just means I can't guarantee to accurately update your score over time.

As for the rest, just explore and find out.

http://www.halorank.com

I'm looking forward to all your feedback and critique.

Crenshaw
April 1st, 2013, 03:00 PM
Well done, i already have a Gandanur dedi server so will jus update to 13.3. would be nice to see this implemented on sapp though.

EDIT: i have my server up and running but how do i register it at halorank.com i dont see an option.

Crenshaw
April 1st, 2013, 06:41 PM
its a waste of time to have ppl play first b4 they can register also i need a reg key for my server and it turns out i have to do that same $#!t which is play on one of the servers first when they dont even display their ip address correct. some link to the external IP and others to their Internal IP which is stupid. so im gonna try this another time not soon though.

P.S. If you could just give me a key that would be great.

Amit
April 1st, 2013, 08:39 PM
People have to play in order to have their hash picked up by the system so that they can register. There's no other choice.

Sean Aero
April 2nd, 2013, 01:55 AM
Your definition of a waste of time is totally of the charts, the process does not take long at all.
In order to help you out on how to sign up you can watch this video:


http://www.youtube.com/watch?v=jb2us2faw0w

As for the ip address displayed, these were filled in by the server admins themselves, so it's quite hard to believe they would fill in the internal ip.

P.S. After you sign up, you can request it.

EDIT: Woke up on the wrong side of the bed this morning, so sorry if I offended anyone.
I'll have a look at the IPs displayed when I get home, might be a small script bug.
EDIT: EDIT: Wrong IP display bug has been fixed.

Kornman00
April 2nd, 2013, 04:41 AM
What are your plans for intergrating this into other server environments besides Gandanur?

Amit
April 2nd, 2013, 05:27 AM
:mech3:

Last I heard there was none because it wasn't possible with SAPP and the such. Things may have changed since then, though.

Kornman00
April 2nd, 2013, 05:52 AM
"wasn't possible"?

How was it impossibru?

Sean Aero
April 2nd, 2013, 07:40 AM
Everything is possible with time and dedicated people.
However the current method used to collect the statistics, as used with Gandanur, is not feasible for other Server App.
Instead a different approach should be taken.

sehe
April 2nd, 2013, 02:09 PM
Well, Gandanur uses HTTP requests and php/java scripts on Sean's side, which means HUGE overheat.

Since I already have a "Global Sapp Server" that uses native TCP stream to communicate with the Sapp servers, used for the auto-updates, and for this: http://elitegameservers.net/sapp/serverlist/ (In the future it could be used as an alternative GameSpy, in case they stop supporting Halo, [that I doubt until there are paid servers]).
Therefore, since I already "had" this I added some stats-sending code to Sapp and stats-tracking to the Global Server that writes the data to a MySQL database (pure C++). These lines are "commented out" atm but I think the hardest part of the work is done already, all that left is testing and integrating/merging these stats with those that Gandanur servers collect.

Kornman00
April 2nd, 2013, 09:46 PM
Instead of directly integrating with server apps, a better route to take would have probably been creating an API, either binary or data based (but not strictly 'database'd). Processing the chat log is one example of what I mean by making something data based. After all, the one thing that stays the same between all server apps is Halo. That should be your only concern. Then you could have your own service running alongside the dedi for handling the API submissions to the site itself.

I don't really see what the problem is with operating over HTTP. Hell, it's what the Halo engine has been using for stats/file transfers since H2. Unless you're performing some kind of heartbeat, meaning all servers are performing communications every X period instead of just at the post game.

Amit
April 3rd, 2013, 02:03 AM
Didn't he mention in the video that it sends statistics every 30 seconds or so to have a mostly "real-time" update system? Otherwise, the Games tab of the site wouldn't work properly for showing stats of the games that are still in progress.

Unless I'm just confusing all of this.

Btcc22
April 3rd, 2013, 02:58 AM
No, that's right. It sends stats at 30s intervals.

Sean Aero
April 3rd, 2013, 04:24 AM
Instead of directly integrating with server apps, a better route to take would have probably been creating an API, either binary or data based (but not strictly 'database'd). Processing the chat log is one example of what I mean by making something data based. After all, the one thing that stays the same between all server apps is Halo. That should be your only concern. Then you could have your own service running alongside the dedi for handling the API submissions to the site itself.


I totally agree here and it is one of the lessons learned from undertaking this project.
When I find a bit more time I'll write a post regarding the lessons I learned from undertaking such a project and the recommendation I would give to anyone else willing to attempt it.



I don't really see what the problem is with operating over HTTP. Hell, it's what the Halo engine has been using for stats/file transfers since H2. Unless you're performing some kind of heartbeat, meaning all servers are performing communications every X period instead of just at the post game.


We make use of an heartbeat, which beats every 10 seconds.
This heartbeat approach was done for 2 reasons, first being able to display more Live data on the website, as I'm still a huge believer of a more dynamic interactive website.
Second was being able to process and check the full game on the HaloRank server, thus making it much more challenging to boost/cheat statistics through memory edit or such.


The 30 seconds I mentioned was just to be sure that the 10 seconds, which is the maximum time from a certain event occurring until a heartbeat being send, plus the process time of the heartbeat on the HaloRank server would be fully completed.
On average once a heartbeat is received it's processed within 5 seconds on the HaloRank server.

When I have a bit more time I'll edit my first post with more information on the reason why certain choices were made as well as what could have been done better.

sehe
April 3rd, 2013, 07:14 AM
The problem is with the HTTP is that if you have 300+ servers the php/java scripts rapes the CPU. AFAIK that's why HaloRank shut down for a long time, cuz it couldn't handle so much servers. + It also gives a lot of network overheat too, while with a server sided C++ app you can can do this with 1/1000 CPU usage and about 1/10 network usage.

Sean Aero
April 3rd, 2013, 08:16 AM
AFAIK that's why HaloRank shut down for a long time, cuz it couldn't handle so much servers.

Main reason was I wrote slow SQL queries, I learned a lot about optimizing the queries since then.
Would be interesting to see what happens to the CPU of the server when the amount of server rises.
Btcc22 knows I keep a close eye on the load as it has been a large focus with this new release.

Crenshaw
April 3rd, 2013, 02:51 PM
EDIT: Woke up on the wrong side of the bed this morning, so sorry if I offended anyone.
I'll have a look at the IPs displayed when I get home, might be a small script bug.
EDIT: EDIT: Wrong IP display bug has been fixed.

Ok thank you.

Kornman00
April 3rd, 2013, 05:15 PM
Are you base encoding and/or compressing your HTTP payloads?

Also, javascript is entirely client side if I'm not mistaken. It shouldn't even factor into his server's overhead.

What's the server setup? Linux, Windows?

urbanyoung
April 3rd, 2013, 06:59 PM
The problem is with the HTTP is that if you have 300+ servers the php/java scripts rapes the CPU. AFAIK that's why HaloRank shut down for a long time, cuz it couldn't handle so much servers. + It also gives a lot of network overheat too, while with a server sided C++ app you can can do this with 1/1000 CPU usage and about 1/10 network usage.

If HTTP is good enough for millions of websites and services, it's good enough for HaloRank. I assume database queries are what contributes most to the server load, and that won't change if you use a dedicated protocol. HTTP doesn't really have that much overhead, especially if you compress it..

Btcc22
April 3rd, 2013, 07:42 PM
If HTTP is good enough for millions of websites and services, it's good enough for HaloRank. I assume database queries are what contributes most to the server load, and that won't change if you use a dedicated protocol. HTTP doesn't really have that much overhead, especially if you compress it..

It's not HTTP/network traffic that's a problem, it's invoking PHP to handle the data that's the most expensive part of the process.

Another problem is that HTTP's inherently stateless which means the database has to be used to provide persistence. That comes at the price of executing some fairly expensive queries to keep track of the data properly.

Kornman00
April 4th, 2013, 06:33 AM
From what I can recall from when I was RE'ing the stats systems of various halo games is that they're able to make use of session IDs, that are generated at the start of match by either the XBL services or their servers (forget which exactly). If I recall, these session IDs are only 64 bits.

All a dedi in this case would have to do is request a session ID for the game to be hosted, and provide that same ID for all traffic. I'd figure HStats would be doing something like this already. You can easily reuse the game start/end datetimes to figure out if a session is active or closed. For heartbeats, you could just have a collection of dedi runtime state data (could do it purely in memory, not database'd) on the HStats server itself.

* When the server gets a heartbeat, it looks up the runtime data for that session, instead of performing a SQL query for every heartbeat.
* If a heartbeat fails to come in at the predicted time, then that runtime state could just be informed that it's now invalid (leaving it to perform invalidation measures, however severe that may be).
* When the game ends and that final heartbeat comes in the runtime state can be removed from the state dictionary and left to do its processing

I'd figure this would be less resource intensive since you're not relying on network resources for actual sessions (as you would with say TCP). You would also be dealing with a small subset of the stats DB using the runtime state (still using the session IDs of course), meaning fewer to zero trips to the DB itself (at least until it comes time to process the stats). It's entirely asynchronous. No session or runtime state is dependent on one another. Theoretically, no players should be in two matches at once so no player transactions/updates should happen at the same time. The bottleneck comes down to receiving and then pushing the HTTP requests payloads to the runtime states.

Of course if you're wanting to present partial results of a current session, some of this goes out the window as you now have to update the DB on some/all heartbeats instead of the final. However, you don't see any games providing the ability to see partial game stats for in-progress sessions, so why someone would want to go that route in a production environment (which can only go up in use) is beyond me.

PHP is able to run DLLs which export C symbols (you could do it in C++ just as long as the API was exposed as plain C) last I checked. So both a Linux and Windows server should be able to run a utility DLL for your more intensive processing that for whatever reason can't be efficiently done in PHP itself.

Crenshaw
May 3rd, 2013, 10:33 AM
so you remember me a while back griping about not being able to create a server to be tracked with halo rank? and you told me your sorry but halorank doesnt track pirates so then why you put this??? i joined a lot of haloranked servers just so that im able to register and to get a reg key for my server but to no avail.




I'm use a shared key/pirated the game or "HaloCE portable" (v1.00/v1.06) user, will my score be tracked?
Your score will be tracked but since this system is based on hash it will be quite hard to keep tracking your progress over time.
If you want to be tracked perfectly within in the system you'll need a legit install of Halo and a legit key. Measurements have been installed to filter out pirates hashes over time, however it can never be 100% perfect. This does not mean you can not play as a pirate, it just means I can't guarantee to accurately update your score over time.

As for the rest, just explore and find out.

Amit
May 5th, 2013, 11:36 PM
and you told me your sorry but halorank doesnt track pirates so then why you put this???

If you read the explanation and comprehend it, then you would understand that it effectively does not track pirates. Why? Because there are so many pirates, so the stats are obviously skewed.


This does not mean you can not play as a pirate, it just means I can't guarantee to accurately update your score over time.

The statement above is clarifying that it is possible to join and play on tracked servers as a pirate, but your stats won't be tracked. Therefore HaloRank does not truly track pirates.

Crenshaw
June 19th, 2013, 03:55 PM
If you read the explanation and comprehend it, then you would understand that it effectively does not track pirates. Why? Because there are so many pirates, so the stats are obviously skewed.



The statement above is clarifying that it is possible to join and play on tracked servers as a pirate, but your stats won't be tracked. Therefore HaloRank does not truly track pirates.

ok fair enough

Tnnaas
August 1st, 2015, 12:54 PM
Vaporware?

Btcc22
August 1st, 2015, 10:35 PM
Vaporware?

It launched but died for various reasons, one of which being that it only worked with Gandanur.

supersniper
August 1st, 2015, 11:09 PM
Yeah, plus I haven't heard or seen from Sean in a while.

Cortexian
August 9th, 2015, 11:03 PM
http://web.archive.org/web/20140517111331/http://halorank.com/

It definitely existed for a while, but yeah... Since it only supported Gandanur, when SAPP was clearly the dominant option chosen for use by server administrators... It kinda died out.