Salted hash? No, I’m not talking about food lol. I’ve been working on the authentication methods between the client and the server. The stored passwords in the database are now hashed using a secure hashing algorithm. No more plain text passwords. I know, sounds bad, but it was strictly for testing purposes. The web site uses SSL encryption, and also hashes the passwords as well. However, I’m still working on the encryption methods for the game client.
I decided to salt our hashed passwords in the client with random bits that are generated on demand by the server. This way a login packet should never contain the exact same data every time a client authenticates and logs in. This is done to avoid a “replay attack”, where a “man in the middle” snoops the login packet, and tries to use it later to authenticate as that client.
Note that hashing is not encryption. Hashing is strictly one-way, and theoretically can’t be decoded. Encryption implies that a decryption can take place.
I decided to enable the Conformance Mode (permissive-) option that was introduced in Visual Studio 2017. It’s supposed to help me write code that is both more correct, and more portable. I found out quickly that it reports a lot of conformance issues! Especially bothersome is the fact that you can’t directly call inherited members in templates that have been derived from. You have to either declare a using statement at the top of your template class to inherit the parameters/members from the base template, or add a scope resolution operator to them. You could also change the call from function() to this->function(). Since ‘this‘ is always implicitly dependent in a template, this->function() is dependent and the lookup is therefore deferred until the template is actually instantiated. It was a lot of work cleaning things up, since this code base is so large.
The Orion Engine SDK has evolved all the way from Visual Studio 6.0, to the most recent 2019 version. I’m very pleased that it still builds correctly and cleanly with all of the strict options enabled!
I made a couple of simple applications that I’ve been using to test the latest client and server code. It’s certainly helped me find and fix a few bugs already. I feel like the code is pretty solid now. I can also use these test applications to send a bunch of “bad” data to my network drivers. You know this will happen once my servers go live again. I can verify that my algorithms, such as the “stale socket check”, are working as I intended. Time to keep plowing forward!
Finally, the new and drastically improved network server driver is working! I’m so excited! I have some quirks to work out still, but all is good. Now, I’m moving on to some encryption and hashing stuff that needs to be addressed.
Getting close to finishing up the network driver code for the servers. I’m finding that I want to re-factor a few network related things in the Orion Engine SDK. I’m finally getting close to a new public test of the game client! I’ve also been further securing the login code. I’ve added some Cryptography related classes and functions to the SDK. Been doing a lot of testing and planning lately as well. It’s all good!
I’ve been working on the network server code over the past week. It’s modular in design, meaning I can replace the existing module on all of the server applications and they will automatically use the new, optimized code. I’m implementing the “Overlapped I/O Completion Port” method. It’s a very complicated implementation! I hope I don’t need much longer to finish it. I feel in the end I’m going to have a very scalable, high-performance server library capable of handling thousands of simultaneous connections!
I finally figured out what was causing problems with my network code! Man, that makes me feel good. Wow, I’ve been tracking this issue down for months! The client networking in the game is working pretty efficiently right about now. While I was looking for the bug, I made several big performance improvements to the network driver. Now, I just need to finish the optimizations with the server code.
I’m in the mood to do some hardware upgrades this weekend. I have some extra spare parts that I’m going to shuffle around.
I’m going to increase the memory of my development box to 32GB. With all of the instances of Visual Studio that I keep open, and the long and memory hungry build process, I figured it was about due. I’m also going to upgrade the old SSD, which is not very big, to a larger one. I’ll also be adding a second SSD, which will be used to hold all of the current development files. This should provide some pretty nice performance!
I’m also going to add an SSD to both of the database servers. The old drives will become the backup drives. Note that the database is also backed up onto my offsite cloud as well. The SSD should really help the speed of these systems!
Well, I finally upgraded our source control to Team Foundation Server 2018. Not sure when, or if, I’ll upgrade to Azure DevOps Server 2019. This is a good next step at least, and it’s working pretty nicely.
The memory in the Team Foundation Server was upgraded to 12GB. That should be more than enough. The file server memory was also upgraded to 20GB. It will be able to cache a lot of files now!
There have also been a few minor updates to the entire web site. The Been There Game web site now has a page to show the current server status. Stay tuned, more to come soon!
Just upgraded the Linux web server to Fedora 30. Still can’t seem to get screen sharing working. From what I’m reading, the VNC server must still be broke or something. Oh well. Anyway, one good thing is I have my web site and it’s MySQL database backups mirroring to a cloud now. In fact, the Team Foundation Server, my file server and the game’s SQL database servers are all backing up to this cloud now! Glad it’s all working as planned.