From a management standpoint, a mature software development process should not allow that first design to ever be implemented. Another round of simplification should be performed before any code is written. The initial design is not wasted time, as it provides insight to future improvements based on the original designer’s concepts. I’ve found that, working on my own, there is often too little oversight in this regard.

So it was with the content management system for the MMORPG platform I’m developing. Since I’m on my own, I could cope with the inelegant-yet-functional initial design. It had several programming-theoretic benefits. For example, I’m a big believer in strong typing and layering, but to the extreme it adds boilerplate code at each layer of architecture. In addition, (against my own advice) much of the design was overly rigid and complicated for the sake of theoretic (unproven) efficiency gains.

The straw that broke the camel’s back was gameplay integration. Adding and changing game content was a multi-step process to integrate properly with the underlying content system. Due to the aggressive byte-packing strategy, database storage was fragile, requiring a complex process to cope with code changes. Altering the gameplay needed to be more fluid, robust, and simple.

The new content design is fundamentally the same as before, but with a radically simpler implementation. As evidence, I dropped over 12,000 lines of code after removing the legacy content structure from the code base. Granted, not every little thing is fully functional yet, but the client and server operate with basic functionality, at least as well as before. Every line of content integration is simpler, with cleaner behavior. Database storage and network transport are more robust.

As a postmortem to the legacy content system, it provided a solid testbed for developing the features needed to support an MMORPG. It served as a proof-of-concept of the fundamental design principles, which are now more elegantly realized in the new content system. Most importantly, the new system shall usher in a renaissance of gameplay integration.

From a software project standpoint, I had to weigh the consequences of the new design versus maintaining the existing (mostly working) design. Anticipating major ripple effect throughout the code, I decided to take the plunge (pun intended).

From a software design standpoint, I planned out the enhancement to avoid breaking existing systems until the last minute, by implementing the new code separately. I moved old classes to legacy packages for easy identification, for later removal. After the new content implementation was working on its own (granted, only with minor developer testing), it was time to integrate the rest of the game systems. To my body of code, it was like breaking every one of its bones, just to reset them to heal in a better position.

Since dis-integrating the old system, it has taken me about five days of furious coding to re-integrate with the new classes. The code is remarkably simpler, and is even more capable than the previous model. For example, I can more easily manipulate content without fear of destroying the entire database! When the old system is expunged entirely, I expect another steep drop in lines of code.

From a software management standpoint, I should have isolated my changes in a branch, to be merged back to trunk after complete. That would have allowed me to support existing releases while the branch remained broken. Also, that would have allowed me to easily abandon my changes if this whole upgrade when terribly wrong…

… which it might still do. At this point, I can compile my 1659 source files, but I’ve not yet run the game with the changes. In fact, I know of several gaps that will cause the system to crash spectacularly, until corrected. Once I have a working game again, I’ll post an update for Alpha Playtesters to enjoy. With any luck, you won’t notice a single difference.

As an initial disclaimer, I am not entirely discrediting the Java Logging API. From a software engineering standpoint, java.util.logging provides a flexible, well-designed logging system, which is fully capable of providing logging services for a variety of applications. However, I have found it to be several times too complicated in the common case, and I disagree with some of its basic principles.

Although I argue against static design in almost all cases, logging is one situation in which you do not want to be passing an instance reference through all your methods. Languages with aspects, other cross-cutting features, or even multiple inheritance can allow logging to be mixed into classes. Since Java does not (natively) support these language features, a static logging API is the cleanest solution.

I do not fault the static design of the Java Logging API, but I take exception to calling Logger.getLogger(this.getClass().getName()) just to obtain a logging instance. The first design simplification I made was to write my own static logging API to encapsulate the ugly details of obtaining the Java Logger. My logging calls look something like Log.warn(this, "message"), which is somewhat cleaner.

All logging systems I’ve ever used have been based on logging levels, and I’ve never agreed with this concept. Logging messages are generated for different purposes, not at different levels. Severity levels make sense for informational/warning/error messages. Other message types do not fit into this model, such as debug, audit, start, stop, and configuration logging. Furthermore, levels named fine, finer, and finest (all lower than config messages) force programmers to arbitrarily decide how important a log message should be. Java arbitrarily includes exactly seven levels, placing further restrictions on extensibility.

I do not blame the Java Logging engineers for following a well-established design, even though it is faulty, in my opinion. Nonetheless, the second design decision I made was to isolate Java’s logging levels behind my own logging categories (fail, warn, info, init, stop, user, debug). My categories are mapped to Java’s logging levels, which are required to call the underlying Java Logging API. Custom formatters output my category names in place of the Java logging levels.

Registering custom formatters and handlers is another example of good engineering becoming somewhat overbearing in the common case. Based on any criteria, Java logging messages can be reformatted and redirected to different files (e.g., summary, detail, error) and sent over the network. While this is a potentially useful feature, the configuration is more complicated than desired for common use.

The third design simplification I made was to limit my logging to one flat file. If category or message source filtering is needed, grep is a perfectly adequate command-line tool. It is more reliable to post-process a complete log file, rather than rely on code changes to adjust logging output. This simplification alleviated any need for complicated Java handler and filter configuration. Since remote logging is useful, I added a few lines of code to (optionally) open a socket and send log messages to a remote server.

At this point, my logging API provided simple static integration from anywhere in my code, featuring source-named messages with meaningful categories. The complexities of configuring and calling the Java Logging API were all hidden behind my static Log class.

With all this effort heaped upon my code just to avoid reinventing yet-another logging system, two straws finally broke the proverbial camel’s back. For one, I had exhausted the seven available Java logging levels and could not add any additional categories. Even more severe, Java tended to stop logging before the application was finished. Log files lost the last lines of logging, because the logging API stopped outputting at the first signal of application shutdown. There does not appear to be any programmatic control over Java logging shutdown timing.

These issues prompted me to make my fourth, and definitive, simplification to using the Java Logging API; I abandoned it entirely. Since the rest of my code was integrated with my logging facade, I didn’t have to touch any code outside my static Log class. My application now initializes my logging system at startup, which involves opening a file, and stops it at shutdown, which involves closing the file. To preserve the best of the Java logging design, I have a simple formatter interface, which allows custom output. To prevent file output from blocking the application, I implemented a simple thread handoff queue, so all log calls return immediately. Flushing this queue is coordinated as part of application shutdown, so no messages are lost (even in the case of unhandled application exceptions).

In conclusion, I agree with the sentiment of not reinventing the wheel by using available software libraries. However, there is little added value when more time is spent dealing with the complexities, anomalies, and inadequacies of another library. There is a tradeoff, which can be both a strength and a weakness, between learning to integrate a software library versus developing it yourself. Although the Java Logging API is entirely capable, in this case, I would have made better use of time by implementing my own, simplified, logging API in the first place.

Attention Alpha Playtesters: I’ll be testing the new Java version soon, with the goal of officially updating the game’s base Java requirements to this version. Playtesters are encouraged to try the new update and report any issues/improvements.

In the rest of this article, I give my two cents on Sun’s approach to Java thus far, and examine a couple improvements I’ve been eagerly anticipating.

Since the beginning (and to its credit), Java has been a language by developers and for developers. By learning the Java Programming Language, developers can leverage the platform’s capabilities for a multitude of applications, including client/GUI applications, networking, server and enterprise applications, database interaction, server-side Web processing (Servlets), and browser-based applications (Applets). Under this developer-centric approach, Sun has underestimated the frustration experienced by end users trying to install and configure the Java Runtime Environment. Although I applaud Sun for remaining true to its target audience of developers, I see its lack of user attention as the major reason Java is not as prolific as it could/should be.

Take, for example, Java Applets. I’m not a big fan of in-browser applications (especially when abused for purposes of eye-candy), but there are some useful features that can be offered by interactive browser-based widgets. As a Java developer, I could leverage the platform to create fully-featured browser-based applications. Sadly, I have had little confidence that a Java Applet would actually execute properly in a user’s browser. The Next-Generation Java Plug-In promises to improve Applet support.

As a more specific case-in-point, Java Web Start should be the ideal approach for players to install-update-launch the Potential Games, Java-based, in-development MMORPG game client (“with a single click”). My experience has shown JWS to be problematic (to put it lightly) under many common conditions. Since Java includes this integrated deployment capability, I’d prefer to use JWS over a third-party deployment system. Java 6 Update 10 promises to make application deployment more robust and transparent to the end user.

In summary, and in conclusion, I feel that Java has been incubating within its developer-centric shell and is only now beginning to break out into an environment of mass acceptance, where it can realize its full potential.

Prior to starting Potential Games, my academic and professional background focused on distributed software security topics. While an online game is more entertaining to play than an enterprise business application, the need for critical security analysis is just as important in both settings.

A potential vulnerability of any software system is injection of malicious data. In an online environment, peers (clients and servers, or nodes in a peer-to-peer network) pass information as a matter of course. Both sides must be especially wary of information being received, which may have been crafted to trigger some undesirable behavior.

This type of attack is old hat in the field of Web browser/server development. Browsers and servers expect messages to be received from a variety of different applications, so they are designed with data validation in mind. Nonetheless, new injection vulnerabilities are frequently identified.

On the other hand, client and server applications for an MMO game are often developed in-house as proprietary software, designed to communicate exclusively. Because of this, the design process might make the simplifying assumption that input data will be formatted as expected. Taken together with constant-crunch-time scheduling, online game software vulnerabilities are sure to be missed.

Improving the software security design process can be discussed in a future article. In the spirit of Cyber Security Awareness Month, the purpose of this article is to raise awareness of potential chat exploits. I have two reasons for choosing this specific topic: (1) Chat messages represent client-to-client communication, which is especially dangerous, and (2) because there doesn’t seem to be much written on the subject.

On the first point, the chat system of an MMO(RPG) provides an open channel for a client application to send data to many other clients. The standard architecture is to relay chat communication through the server, subject to game rules, such as character proximity in the world. If the content of the chat message is not carefully sanitized by the server, clients could be fed malicious data, which was crafted by a hacked client (or simply cut-and-pasted as a chat message). The situation could be particularly dangerous if the software designers of the game client made the simplifying assumption that data from the (proprietary and trusted) server is safe. For these reasons, it seems that in-game, player-to-player chat engines would be particularly vulnerable to attack.

On the second point, I haven’t been able to find much information on actual chat-based exploits. A centralized server architecture provides an obvious location to sanitize chat messages. In practice, the state-of-the-art in MMO game systems may already avoid chat exploits. However, in the generally more open (and therefore inherently more secure) environment of Web browser and server software, vulnerabilities based on the same security principles are regularly uncovered. For these reasons, I must conclude that chat exploits are more prevalent than is openly discussed.

Despite the tingling of my security senses, these problems are either (a) already solved, or (b) are known by insiders who don’t want to talk about them, or (c) are known by outsiders who don’t want to reveal them, or (d) are lurking in the darkness waiting to be discovered. Most likely, the answer is (e): (b)-(d). Since the insiders tend to ignore problems that are presumed unknown, and the outsiders have more to gain by concealing the exploits they do know, open discussion is the best way to proactively address security issues.

Anyone with further reading or insight is encouraged to comment. Here is an excellent article describing an Age of Conan chat exploit: Age of Conan hyperlink exploit vulnerability fixed.

TIP: Any and all security techniques (including these) should be considered experimental until thoroughly reviewed by the security community.

The most common form of login (gaining access to a system) involves transmitting a username-password pair (the user’s credentials) to a server for authentication (confidence in the user’s identity) and authorization (right to access said system). This article describes techniques used by the Potential RPG platform to improve login security, but the approach can be applied to any similar system.

The first step to improving login security is to avoid exposing a user’s plaintext password. The common approach is to hash the password, sending the resulting hash value to the server in place of the plaintext password. The server compares this hash value against the hash value stored in the player’s account. Thus, the hash value of the plaintext password (along with the username) becomes the user’s authenticator. The plaintext password is never stored or transmitted. The hashed authenticator can even be stored on the client to allow automatic login.

TIP: Legacy software (and many Web-based applications) send the user’s plaintext password over the network. No modern software has any excuse for ever transmitting or storing a user’s plaintext password.

This basic form of hashing conceals the plaintext password, but has several weaknesses. Suppose you use the same password for several sites (TIP: Don't.). Even though your plaintext password has not been revealed, the hashed authenticator still grants access to your account on any system using the same hash function. Similarly, different users with the same password will have the same hashed authenticator. Since many systems use the (legacy) MD5 hash function, a simple hash is not sufficient to protect your credentials.

TIP: Don’t use the MD5 hash function. Minimally, use SHA-256. Consider going one step further and use the double-hashing technique defined in Practical Cryptography (Ferguson and Schneier, 2003).

The Potential RPG platform protects your password by mixing in additional information when hashing. Specifically, your password, username, and a system-unique value are hashed together to form your login authenticator. By incorporating these values, each authenticator becomes specific to this game and the user. The authenticators cannot be used on other systems, even if the user has the same password. Users with the same password will not have the same authenticator.

As an added bonus, the above technique defends against dictionary attacks. The purpose of a dictionary attack is to reveal the plaintext password of a hashed authenticator. Dictionary attacks against basic hashing work by pre-computing a dictionary of hash values for all possible passwords. If your hashed authenticator is in the dictionary, your plaintext password is easily revealed. A single dictionary can be used to expose the passwords of many users, for any system using basic password hashing with the same hash function.

By mixing in a system-unique value and username with each password, a dictionary would have to be computed for each system and for each user. This essentially renders a pure dictionary attack more expensive than would be worthwhile.

TIP: Making an attack more expensive increases overall security.

Consider a more valuable target: The server’s database of user authenticators. Before storing any authenticators or authenticating any logins, have the server perform another round of hashing. The one-way nature of secure hash functions effectively devalues the authenticator database, because those values cannot be used to log in.

TIP: Devaluing a target increases overall security.

Unfortunately, all this password hardening still does not secure the login process itself. If an authenticator is stolen from a client’s cache, or in transit to the server (during login), that authenticator can be used to log in as the user. This is an example of a replay attack (the login information is copied by an adversary and resent later). The password hashing techniques described are still a valuable component of the security system, providing defense in depth, but another layer of security must be added to further protect the login process.

Several strategies can be used to protect and conceal data in transit, but this article only covers password hashing. Besides, this is only Cyber Security Awareness Month. This month, I only need to make you aware of security issues. Later, we can discuss how to defend against further security vulnerabilities.

UPDATE: After writing this, I realized another benefit to good password hashing. If all systems salted and hashed your password as described above, you could safely use the same (plaintext) password everywhere. The hashed result would be unique per system. This sounds good from purely a client-server standpoint, but you would be more susceptible to keystroke logging, which would then be capturing your universal plaintext password as you type it into the keyboard.

The static keyword (in Java) is an important language feature, but can be easily abused, leading to several problems.

One problem is static cling syndrome: Static methods beget static methods. Once you start coding with global access methods, other parts of the system tend toward static access. Eventually, the design degenerates into unmaintainable spaghetti code.

Another drawback is initialization. A static system that requires an initialization method to be called is error prone. Consider Java’s class loading system, which may trigger static method calls just by accessing a class.

Purely static code may also break other software features, such as modular component design. The static API can be called from any object in any module at any time with no access control or coordination. In some cases, this type of global access is desirable. For example, a fully instance-based (non-static) logging system would require passing the logging object throughout the code, permeating every class with its presence.

If your code has given in to the dark side of static design, do not despair; there may still be some good left in it, and you may be able to save the design before it destroys itself. Attempt to reform the design by rewriting it with instance-based objects. This is your library implementation. If global access is needed (as with the logging example), follow the singleton pattern and provide static access to a single instance of the system.

Do not underestimate the power of an object design. Even though it still involves global static access, the singleton provides several benefits. For one, you can eliminate static cling by implementing helper classes as objects. Premature access problems are eliminated (or at least exposed), since there is no singleton instance to call until proper initialization is performed. The singleton pattern tempers the dark side, and is the tool of a more civilized design.

You might tell yourself that you’re not afraid of the dangers of a static design. Once you are faced with debugging an evil static system, only to find that your adversary is your very own code staring back at you, you will be; you will be…

First, consider the cases in which data serialization (a.k.a. marshalling and unmarshalling bytes) are used on this project. I am serializing objects for client-server network transport, client data cache, and server persistent storage. Without any special care, any class changes could/would break compatibility with old versions of the data. This situation is evident to any Alpha Playtester, as I usually wipe out the database after major updates.

Notice that client-side cache data can be (and is) expunged if any data structure has become incompatible. Also, since I’m using Java Web Start (at least provisionally), I can assume all users are running the latest version of the client software. Therefore, transport compatibility is not a big concern. Nonetheless, other projects may support clients of varying versions. Although I’m not explicitly dealing with this scenario, the technique described below could be used to support forward compatibility.

For the server, serialized data must survive code changes.

The standard advice is to avoid the problem; either maintain yet another external data format, or never change your objects. Since the former is undesirable, and the latter impossible, I’ve attempted to come up with a more robust approach.

Although Potential RPG is (so far) 100% Pure Java, I am not using Java’s built-in Serialization mechanism. Java Serialization is designed (rather elegantly, actually) for convenience at the expense of robustness. Even for core Java classes, the documentation explicitly warns that serialized data is likely to break between Java versions. Using Java’s Externalizable interface is an option, but this still binds the developer to Java’s Serialization mechanics.

The approach I’ve developed is an object packing/unpacking system, in which each serializable class has an accompanying byte-handling Packer helper class. This is functionally equivalent to a class-based Externalizable system (but with a cleaner API, IMHO).

The problem of survivability remains. The one-byte solution is to insert a packing schema version byte before each object’s data. This version is given to the unpacking method when unmarshalling the bytes. The unpacking method can include logic to (a) skip defunct fields and/or (b) set default values for missing fields. This technique provides backward compatibility. (Adapting to future versions is more complex, so I’ll ignore that on this project…)

Under this design, maintaining backward data compatibility for a class is a matter of augmenting the unpacking routine. Notice that the packing routine always produces an updated serialized data structure. Therefore, it is possible to write a routine that upgrades the database in one pass; or, the server can be left to lazily update objects as it encounters them.

For Playtesters, the next Alpha release will impose a mandatory database reset. After that, if I am diligent in my code, the test world should survive future updates.

Further reading: Durable Java: Serialization

Background: I have a class (let’s call it Subordinate) that has special control methods, which should only be called by a Master class. (Subordinate also has methods for public use.) Consequently, I originally implemented the Subordinate in the same (client-side) package as the Master, using package-protected control methods. Unfortunately, this binds the Subordinate, and everything that needs it, to client-packaged libraries.

Simple Solution: The simple solution is to repackage the Subordinate into its own (non-client-specific) package. Unfortunately, the control methods must become public for the Master (still bound to client-specific logic) to access. The API would have to document, “Please do not call the control methods, unless you’re supposed to.”

The Goal: My goal is to provide a Subordinate that can only be controlled by the Master. One approach is to create a Subordinate interface, and keep its implementation hidden. However, there is no desire to allow any other implementation of the Subordinate (it is best kept final).

Concealed Controller: The crux of this pattern is a Subordinate helper class, called Controller. Controller has access to the (once again) package-protected control methods of the Subordinate. The Controller exposes public access to the control methods. In addition, the only way to obtain a Subordinate is to construct a Controller (which constructs the Subordinate instance internally).

Integration: To use a Subordinate, the Master constructs a Controller and exposes the contained Subordinate publicly (but conceals the Controller for itself). The only access to the Subordinate’s control methods is via the Controller, which is concealed by the Master.

Pseudocode:

package library;
public final class Subordinate
{
    Subordinate() { }
    void control() { ... }
    public void action() { ... }
}
 
package library;
public final class Controller
{
    private final Subordinate sub = new Subordinate();
    public Controller() { }
    public Subordinate get() { return sub; }
    public void control() { sub.control(); }
}
 
package client;
final class Master
{
    private final Controller control = new Controller();
    Master() { activateWhenClientIsReady(); }
    private void activate() { control.control(); }
    public Subordinate get() { return control.get(); }
}

Potential RPG: In my code, the subordinate is a PlayerCharacter class, with activate() and deactivate() control methods, only to be used by the client-side CharacterAgent (master). Many GUI classes integrate with PlayerCharacter, which provides access to the in-world character being controlled by the player. Following this pattern, the CharacterAgent constructs and conceals the Activator (controller), shielding access to the control methods (thus preventing the chaos that would certainly ensue).

The generation is the major version of the software. A feature release indicates the completion of a set of available features. Incremental releases may include bug fixes and enhancements, as well as new features that might not be fully integrated or ready for a feature release.

Incremental version numbers are treated as steps toward the next feature release. The test environment (including Alpha testing) should see all incremental releases. However, the production environment (when there is one) may skip some incremental releases, but should see all feature releases.

In practice, this versioning plan may be too linear. For example, a bug that affects the production environment may need to be fixed before any next release is ready. What is more, the latest incremental release may include features not ready for the production environment. Branching is the revision control mechanism that deals with this, which must be accounted for in the software development process and release management scheme. For Potential RPG, I will probably resort to a fourth patch level version, indicating something was fixed outside the mainline of development.

In addition to the software version number, I also include an edition (”Alpha3″), which is a marketing version name, the repository revision whence the product was built, and the build date/time.

Here’s a handy article on retrieving the Subversion revision from within your Ant build script. Anyone with further advice/insight into the exciting world of version management is encouraged to comment.