Development Update - 05/16/2012

[Mycal]

I've started typing this up about 8 different times and each time, either didn't finish it or started rambling. So I'm going to start over and keep it short and sweet.

I've got about 10 days to decide the direction I want to go with Odyssey. I've been working on an ASP version of the website which will make server/client->website interaction so much simpler and is much easier to work with than PHP. However, since I am an ASP newbie, it's taking me a lot longer to get anything off the ground. If I can get basic website accounts working fine then I can move onto client/server secure authentication. If I can get this done in a few days, then all of my websites may move to a new server that is windows based. If I can't, I will have to scrap what I've done and write it in PHP, which is feasible, but takes longer due to the nature of PHP. Alternatively, if I can find a cheap enough host, or make proper use of my Azure hosting that I have for free, I'll just move servers for Odyssey and leave everything else here at Bluehost.

Either way, I need to make a decision fast since my hosting is about to expire here with Bluehost.

Anyway, that's what is currently going on and I'll make sure to post updates whenever I get something working on that end. I have a lot of things relating to server conversion swirling around in my head that's troubling me, so I'm probably going to have to sit down and just hammer those out to figure out all use case scenarios.

 

[Mycal]

I think I have worked through all issues with converting a server's players. Since we are using master accounts instead of local accounts with the new version of Odyssey, there were some issues I saw with the players. I'll talk a little about them below.

Base use case scenario:
A server owner (SO) runs 3 different servers. Each server has about 100 maps, 10 scripts, 2 gods, and 10+ players.

In Odyssey, each player has a username/password combination. This is the only unique determining factor in identifying a player to a server. In order to convert a player we need to create a globally unique identifier (GUID) for the player and send this GUID, User, and Encrypted Password to our webserver. The webserver then does a few things. It converts this encrypted password into a more secure/non-reversible format and saves this information into a temporary converted players table. Once in the temporary database, it will attempt to match the exact username and password to the real players table.

If the entry exists, it will take the real GUID and pass this back to the converting server which will store only this ID as the player identifier in the player's table.
If it does not exist, it will do nothing and the server will then store the the temporary GUID as the player identifier.

These are the two easy scenarios for conversion. However, if the username matches but the password does not, it becomes tricky and this is the scenario I have been most concerned about.

Let us say that each of these three servers in the base case all have a player named BigRed. Each BigRed also has a unique password. Odyssey does store half of a player's IP address, so we can do something like match the IP address to the stored IP address and if they are the same, store every password and after the player logs into the website the first time, store the password they used as the real password. However, we are still left with the scenario that they are in fact different players altogether. In this case, the webserver should probably then make a new entry for each of the players into the database, each with uniqueIDs and give each one a temporary username and force the player to choose a new name when they login for the first time. Finally, this presents one more issue. Suppose, that all 3 of those BigReds really were the same player, but he used different passwords on each server and had a dynamic IP.

In this scenario, we generate an unique identifier for that user's machine, meaning no matter what, if we generate this identifier on this machine, it will always be the same. We send this off with their login request and store this identifier along with their IP address in a link table. This gives us a little extra information about a player. Now say the first of those BigRed accounts logged in. We do not force this player to change his name, since going by normal naming rules, he was the first one to "register" and claims the name. Now assume some time after, he attempts to log into server 2. When the login request with his machine uniqueID is sent, we match it to the link tables. Since the player originates from the same machine, we grant this player access. If he didn't match, we would then enforce the name change rule.

I believe that covers all scenarios and allows full conversion of all player information. Hopefully this is true, because now I can make some real progress on this instead of constantly changing my mind since I didn't think about this or that.

In other news, I think I will stay where I am at webhosting wise for another year. Odyssey will move to a separate host in order to stay an ASP application. Over the years, I've come to despise PHP and I truly wish to stay away from it if possible. It is the absolute worse programming language known to man in my mind now.