3 Ideas to Get the Players Tab Back

Sort:

windsinger

Dec 14, 2008

Hey guys, its me again. I moved recently and the internet connection I currently have prevents me from spending as much time as I would like playing on Live Chess. I checked a while ago and I saw that the player's tab is not back up yet. I know that you guys are currently working on getting it back and you have done a great job of making the Live Chess experience as stable as possible.

Any way without further adieu let me contribute three ideas on how to get the players tab back. These ideas aim to reduce the stress on the server in one way or another since it was publicized that stress on the server caused the players tab to be removed.

Idea 1

This idea is a further development of my suggestion 2 in another post located here. I have updated the post (well, replied actually) with a sort of case study to put into context how it might be implemented. Now what I am going to elaborate here are the ways and means with which it might be implemented.

In brief, the idea is to outsource non-vital server function to "volunteer" members who likes to donate their bandwidth by running a light server on their computers.

This is the logic for when somebody requests for the players list. I'll write it in pseudo-code because I do not have the luxury to create flowcharts.

player list request from a specific ip_address
if ip_address belongs to same_geolocation_as_volunteer_server
if volunteer_server is still connected
redirect player_list request to volunteer_server
else
serve request

Meanwhile, this is the logic between the main server and the volunteer server

send players_masterlist to volunteer_server
if chess_player enters && volunteer_server.status == still_connected
send request for new_player.status_change to volunteer_server
if chess_player exits && volunteer_server.status == still_connected
send request for new_player.status_change to volunteer_server
if new_chess_player creates a new_account && volunteer_server.status == still_connected
send players_masterlist addendum to volunteer_server

The masterlist only contains public information regarding the player such as username, country, status, etc. Since the volunteer server already has a masterlist of players, it doesn't have to redownload the updated players list, it just needs to change the status of the concerned player to its appropriate status or add to the existing master list.

if received new_player.status_change
if new_player.status == offline
new_player.status = online
else
new_player.status = unavailable
if received players_masterlist addendum
players_masterlist = players_masterlist + new_chess_player

The volunteer server will then only serve the players who are available when someone requests for a player.

Well, since the volunteer server only exists to serve the players list, then it will not need to be huge and it will not require as much resources as the main server; thus it can be run in a desktop computer. Moreover, since it will only serve a limited number of requests and all are text-based, it will not consume much bandwidth.

Ok, so how will the volunteer server be implemented? Well, since it can be run on a desktop and the volunteer member is sort of playing in Live Chess on a browser, then it might be a good idea to run the server on the browser itself.

There is a handy firefox extension for this POW or the Plain Old Web Server Extension might be enough for a volunteer server to be able to serve the players list with a few modifications.

Idea 2

I must admit that the previous idea requires some sort of overhaul to the system and thus may be impractical, error-prone and requires lots and lots of work. So as an alternative, I have Idea 2, a refined version of Idea 1. Idea 2 revolves around three concepts:

Preemption - If a player is connected, it might be better if the server can preempt the needs of the player. That way, the player doesn't need to request for this, and request for that (I will take my guess that processing a players request for certain things takes up valuable server resources).

What if the server only needs to know that a player is online to be able to serve the players list, the seeks list, the chat box in one go? That way, the players doesn't need to make persistent requests to the server. That way, the server won't waste valuable resources processing request that it will serve one way or another. This might also reduce lag. So how can this occur when requests to the server always needs to be done by the player in order to receive an update of the system? This brings us to the second concept.

2. Continuous Download (Streaming) - What if all the data (such as the players list, the seeks list, the chat) needed to be displayed on the broswer is contained in a huge file that is constantly being streamed from the server to the player. As things change (like when a new player enters, or when there is a new line of text in the chat box, or when a new seek is created), the changes are added to that file, so theoretically, as long as the player is logged in, he will not finish "downloading" that huge file. Perhaps that file can be an XML or a JSON stream.

Well downloading a huge and potentially neverending file can be disastrous for the user, and there might not be any way to download an ever changing file. So the last concept attempts to solve these problems.

3. Increments - So what if the huge and potentially neverending file is chopped into one large file (initial state of the system) and increment files (changes made to the initial state of the system). The increment can be an arbitrary number with which the server will check for changes before saving it into a file and pimping / pushing it into the stream (like every 100 ms or something).

The large file in the initial download may contain certain functions and rules as to how to respond to the code in the increment file. So for example, the player initially downloads the list of players online when he logs in. And when a new player enters, the increment file might have something like this:

NEW PLAYERS: player1, player2, player3

In the initial download, the player's list might contain a function that interprets this particular increment:

if NEW_PLAYERS == has_value
players_list = players_list + NEW_PLAYERS

So the player doesn't need to download the whole players list every time he makes a request and he doesn't need to update often (just when a new player arrives, just when he needs to update).

To put it another way, the idea of increments is this: What if the role of the server and the clients become reversed. Such that the server becomes the client and the clients become the servers. If in the normal world a client can make changes to the server, then in this ideal world (where the clients and servers are reversed) one "client" making mass requests can change the status of each and every "server" that it is connected to (this is how my suggestion 1 here comes into the picture).

Idea 3

Idea 2 sounds nice in theory. I personally like it. But implementing this theory may be fraught with many technicalities such as browser stability among other things. That's why my third idea is the most practical among the three and doable as it is (well, if you like it, that is).

Considering the setup before with:

Seek Tab containing PLAYERS who want to play
Games Tab containing PLAYERS who are playing
Players Tab containing PLAYERS in Live Chess
Friends Tab containing PLAYERS who are your friends

Well, I can see that the PLAYERS easily became too redundant with one player which may appear in three tabs!

So how about we reduce the redundancy in the tabs. How about this setup

Seek Tab containing PLAYERS who "want to play"
Games Tab containing PLAYERS who are playing
Inactive Players Tab containing PLAYERS who do not "want to play (seeking for games)", and who are not currently playing a game.
Friends Tab containing PLAYERS who are your friends

I have noticed that usually when players on Live Chess reach 500, there are usually about 150 games, and about 20 seeks. So for the Inactive Players Tab, the server only needs to output 130 players.

500 - (2 * 150) - 20 = 130

I don't really know but this may reduce the stress on the server because instead of serving 500 players, it now only needs to serve 130. And users now get a somewhat more complete overview of players on Live Chess and what they are doing.

I know that you may already be putting the finishing touches on whatever course you have decided to take on regarding the player's tab (which will not necessarily be in any of my suggestions). But I still feel like communicating these ideas before I go to sleep. So bye for now, sorry for the long post.