MV3D Development Blog

Things that I’m unhappy about leaving out from the first open source MV3D release:

• Trees and Grass. They got lost in a refactor (since they were a hack) and were never reimplemented correctly.
• The in game editor. It’s dead Jim, kick it if you don’t believe me. Implementation sucks anyway.
• More stable data storage. Not that I’ve had any problems with it, but showed me the light (as usual).
• A Linuxy easy install
• Load balancing. Borked a while ago with some change and never updated.
• All your CPU are belong to simulation service. It uses as much CPU time as possible currently when it should probably calm down a bit if nothing is going on. Easy fix, but next release.

Things I need to get ready before said release:

• Need to set up one of the MV3D server boxes as an account/directory/asset server.
• Need to QA / fix bugs.
• Need to settle the license issue (which to use).
• Need to do some load testing

Things I’m happy with about the release:

• The authentication. Is very nice.
• Stability(*).
  
>>> print float(s.Uptime())/60/60/24, "days"
206.242458476 days


• The code cleanup. Modules make way more sense now, and everything is Twisted coding style.
• That the foundation / framework should now be in a stable state and ready to build more complex things on top of.
• Modularity / flexibility. I’m loving the new service setup.
• The JSON RPC over HTTP. Is pretty cool.
• Errors! Well, error messages. Don’t know what I was thinking before (mostly it was a lack of understanding on how to properly handle errors in Twisted), but errors used to get silently ignored more often than not.

Things I hope to have in the next release:

• A shorter dev cycle.. 1+ years is too long between releases.
• More unit tests.
• Better logging.
• Eye candy.
• Working character generator.
• No more need for Ogre’s “Media” folder
• A persistent world. It’s possible now, but with no world editing tools, it is rather limited.
• More web interfaces. Got one on the account service now which is very basic, but really nifty.

Things my cat just licked:

• My printer
• My scanner
• My desk
• The DVD I was printing (sorry Cheryll)
• The paper label I was also printing
• The trash bag in my trash basket
• My monitor
• My laptop
• The VHS tape I transferred to DVD (sorry again Cheryll)
• The floor
• My other cat
• Himself
• The feather cat toy he just dragged in that is 2.5x his length

His favorite of the five senses is taste apparently. And I think he’s giving me a hint with the toy, so better wrap this up.

(*) I’ll be very sad in a few days when I shut down that MV3D server process to upgrade it.

So, one of my upcoming tickets that I’ve been forced to think about is moving around the package layout of MV3D so that it makes more sense. The current layout is not very pythonic, there’s a lot of modules named the same as the classes they contain, lots of implementation in __init__ files, etc. Here’s my first whack at reorganizing it:

Any comments or suggestions are welcome. I wish I could avoid the 4 level imports (mv3d.client.service.sim) and also something better than “from mv3d.server.model.realm import Realm” would be good, but I can’t think of anything. The area/realm/object files are large enough that they should exist on their own. Some things still need a better name (especially ClassGenerator, which really just needs to die).

One thought I had was to move client/service/* and server/service/* up one level.

I just finished up the new authentication code for MV3D. I’m very happy with it. It works similarly to my last post, more or less. A client establishes two way trust with a login server, the login server creates two random passwords and a unique identifier. The client logs in to the desired server using its username, unique id, and the first password. That server establishes a two way trust with a login server and retrieves the random passwords for that user/unique id combo. It validates the client’s password. The client can initiate a challenge response in order to verify that the server knows the second password. Thus, a two way trust is set up between the client and the server without the server knowing the client’s real password.

One cool thing is that I added a permission to Accounts using MV3D’s security system to grant or deny a server’s account from authenticating the target account. So, it would be possible to let someone host a server that certain accounts could log in to. The specific accounts would be controlled by whoever is running the Account server / login server (i.e. me).

The only thing I can think to add here would be to give each server a unique id (probably using SSL certs or ssh keys). That way, a client can have a list of key fingerprints from trusted servers like SSH does. This would fend off the case of an attacker who gained the login credentials of a server making their own server.

What’s next on the agenda? Mostly code cleanup. In fact, the authentication tickets were the last tickets for new features in this release. I’d like to release most, if not all of the code when I do this release as well. However, other than code cleanup, there’s some infrastructure tasks I need to do before releasing the code. Then after that, testing. There’s currently a few unit tests that fail which will have to be fixed, I’m also going to want to do some load testing of the login and account services. Basically, my plan is to run the official MV3D account server, so I’d like to make sure it’ll function well with say.. 100x the anticipated load. I don’t anticipate much load, but I would rather be able to handle the very slight chance that MV3D generates a lot of interest.

By the way, just to start setting expectations now. Don’t expect to be blown away by the open source release. I’ve completely concentrated on the foundation of MV3D. It’s just been me working on it, and there is definitely no amount of game built yet. Even after the cleanup I’m doing, the code will need a lot more. There are way too few unittests, and I’m sure some of the older code is just plain old wrong. However, the foundation is there, I feel it’s very strong and flexible. It is very possible to build a game on top of what exists now. In fact, that’s the main requirement for this release since the next one includes content.

Speaking of things I need to do to prepare for a release… I know some people who read this maintain a publicly available Trac instance. What’s the best way to keep the spam off? Even when I was running mine on port 8080, I was getting enough spam tickets that I had to set it to require a login in order to modify tickets / pages / etc. I’d prefer if people could post tickets without asking me for a login because the less hurdles in the way of people reporting bugs, the better. I’m also considering sending www.mv3d.com to trac.mv3d.com. Does that sound like a good idea?

Finally, once I get it up, I’d love to have some people hammer on the login server. It’s got a standard web interface (thanks to Nevow) so people can create accounts or change their passwords. More details to come soon.

So, pointed out some holes in my authentication scheme. Apparently authenticating two untrusted entities via a third trusted entity is tough. Also, PB doesn’t support what I was trying to do anyway. Here’s try #2:

A = Account server. This guy actually holds the account details like passwords
L = Login server. Could be the same as A
C = Client. The one who wants to make the connection. Could be a server really.
S = Server. The one who the connection is being made to.

1. C logs in to L
2. C calls L.createPasswords(unique id)
   1. L calls A.createPasswords(username, unique id) returns two random passwords, a login password and a server password. Both encrypted with a key that C knows. The passwords are attached (via the unique id) to username’s account.
3. C calls S.login(username + “:” + unique id, login password) this is over PB, so it’s challenge response, etc.
   1. P logs in to L
   2. P calls L.getPasswords(username, unique id)..
      1. L calls P.getPasswords(username, unique id) this returns the two passwords (encrypted with a key P knows).
   3. P checks the login password against what C gave it and grants access if it matches
4. C calls P.challenge(random data)
5. P returns a md5 digest of the challenge plus the server password
6. C verifies the server password against the one the login server gave it

Assumptions:

• Connection between L and A is secure.
• L and A are intended to both be servers run by me/MV3D.
• L and A are separate servers since L is a publicly accessible server, so it shouldn’t have account details on it.
• Communication between any server and L is under SSL.

Holes: If either C or P’s login user+password is compromised, they can be impersonated.

X Logs in to L

1. X calls L.challenge() which returns random data that is recorded in X’s session on L
2. X AES encrypts time, username using the md5 of the challenge and username’s password
3. X calls L.authenticateSession(username, AES encrypted data)
   1. L calls A.authenticateSession(username, the random data, the AES encrypted data)
   2. A validates the encrypted data and returns non confidential account info to L plus AES encrypted original time, A’s server name
4. L returns the encrypted data from authenticateSession back to X

Apologies if this makes no sense, or if it’s completely dumb. It’s late, and I should really be asleep and not trying to solve authentication problems.