TriadCity Message of the Day
2002-07-14

Over the next several days we're going to test a major evolution of TriadCity's underlying networking technology: the portion of the server code which communicates with your browser as you play.

This upgrade takes advantage of new capabilities in the Java platform. It allows our server computers to more efficiently service very many players at the same time; and, it helps insulate the game from glitches in individual player connections.

We've tested these enhancements as well as possible in our development environment. Now we need to test them in the real world. We plan to run the new code for a few hours at a time, switching back and forth between old and new code as we evaluate.

Please bug anything unusual: lost commands, duplicate commands, strange logouts, etc. We don't think any of these things will happen, but then, that's why this is a test. The new code is version 0.51.2.0 (the old code is 0.51.1.0).

Here's the technobabble, for those interested:

Prior to version 1.4, Java's networking model was simple but inefficient. Servers like ours assigned one Thread per logged-in user. This was not difficult to implement, and works fine with a small number of concurrent connections. But, under load, e.g. larger numbers of simultaneous logins, the overhead of servicing multiple Threads begins to outweigh their benefits.

Additionally, Java's network sockets were "blocking" sockets: that is, the controlling Thread spent the majority of its time idling while waiting for the arrival of new network input to process. Not super good use of system resources.

Lastly, Java's networking code tended to create very large numbers of new objects while processing. These had to be garbage collected, and thus added some quantity of overhead to the runtime.

J2SE 1.4.0 introduces the "New I/O" system specified here. NIO addresses these performance problems, potentially enabling Java-based architectures to process hundreds of concurrent connections.

First, it enables multiplexed i/o: that is, allows a single Thread to service multiple connections. This is far more efficient, since connections are idle about 95% of the time while you're busy typing. Instead of one Thread per login, we can cut it down to one per ten or twenty logins and still have cycles to spare; and we can create a central pool of Threads which can grow or shrink dynamically as the load requires. Much better.

Second, the new code is non-blocking, which is required of course to enable multiplexing. But this has the additional benefit of partly shielding the server from user PC or modem crashes, and other inevitable network glitches.

Finally, the new architecture uses native OS buffers for i/o processing. This should be more efficient generally, and will definitely cut down on object creation and garbage collection. Cool.

These enhancements should help the server more easily handle considerably larger numbers of players. We think it should handle a couple of hundred. They'll also indirectly speed up the web site, which is running on the same machine at the moment.

This upgrade is Phase 1 of a two-part plan. In Phase 2, we'll move to yet a different architecture, called Sandstorm. This is an advanced, queue-based design which will allow us to radically decouple i/o from command processing. We think Sandstorm will enable 500 or more logins; and will also completely shield the server from any network problems experienced by individual connections. Sandstorm requires a major shift in our program design, and will take a while for us to learn and implement. Look for it in a few months.

Thanks! Let us know if you experience any weirdness, or other obvious changes.

Back to the MOTD archive index.
Back to the current MOTD index.

Not yet a member? Get started today!