After the break

So I took a break from coding and design for a bit.  I’m back, and what I’ve been grappling with over the last little while have been the following questions:

How can I make a login server and game server that can work together to verify login credentials, allow registration, and be relatively secure without tying up the game server’s time waiting – with as little threading as possible (threading makes the complexity of a program increase in factors, I am avoiding where possible)?  After some research and asking around some of my coder haunts online, I have an idea.

First, let me start by saying a custom client will be necessary.  I had hoped to avoid this, so that anyone with a telnet client could connect.  Now I see that in order to create the sort of robust player experience I eventually want this MUD to offer, we really need to customization and standardization that a custom client would allow.  Coding for one client is easier than coding for two or more, obviously.

Basically, my quandry was how to pass a “Socket” which represents the player’s connection, from the login server to the game server, in a sort of “hand-off”, after the login server allows registration or validation of existing credentials.  This is probably not impossible, but is not going to be easy and really is not necessary.

One other option we have is the algorithm I have decided upon tentatively to handle this issue.  The player connects to the login server, which gives the option to register or login.  At the end of either process, the server generates a one-time use hashcode by random and assigns it to this player’s account in the database.  This hashcode and a timestamp is serialized using XML, and stored in a file included with the custom client.  The client automatically then disconnects from the login server, and connects to the game server, using the username, hashcode, and timestamp.  If the hashcode matches the database, and the timestamp is not more than a set amount of time old, login is successful.  Either way, the database then wipes the hashcode, and will not generate another until the player attempts to login.  The game server will not allow a null or blank hashcode from the client, thus it will not be possible to connect to the game server without having gone through the login server first.  One possibility, for added security, is instead of having the timestamp on the client computer, to have the timestamp in the database instead, associated with the hashcode.  That way, a player could not “fudge” the timestamp.

Thoughts?  Suggestions?  Can you think of anything that might improve this procedure?

~ by merlinfire on September 28, 2009.