Cyberspace in the 21st Century
Foundations II

Cyberspace: the next online revolution –- massive multiplayer online games supporting billions of players, simultaneously.

You’ve seen the Web. Almost the entire planet is wired up. Everyone uses e-mail to talk to each other now, and even the telephone has changed. We’re going mobile, even wearable – other services are arriving such as SMS, WAP, I-Mode, etc. Millions of people even have their own web page. We are all connected as equals in this world and we work and play together in harmony. It’s one big global village and we’re going to find ever more sophisticated ways of telling each other stories and having adventures together.

If you thought the five digit figures for players connected to online games was large scale, you’re just seeing a MUD on steroids. Wait until you see an online world as large as the web, unfettered by bottlenecks caused by primitive client/server technology.

Everyone is gradually waking up to the fact that for an application to be of this global scale, it must be a distributed system. Consider file and resource sharing facilities such as Napster and MojoNation, tools such as NetZ, and games in development such as Atriarch. People are beginning to see that the future is distributed. Not everyone believes that global scale applications stopped with E-mail and the Web.

So, if you want to move on from small scale online games such as Ultima Online, Everquest and Asheron’s Call, toward global scale virtual environments such as those depicted in movies such as The Matrix, Tron, and Dark City, then you’re going to have to wrap your brain around the distributed systems approach.

In a nutshell? Well, instead of sharing files as with Napster, you’re sharing the latest news concerning the state of the game model. Some of this news is created by each player when they make changes to their environment, but mostly each player subscribes to the news concerning that part of the game world that they’re currently interested in. Each player’s computer processes the portion of the game model they possess locally. It will seem difficult to believe that this can work for real-time information just as much as MP3 files, but then that’s the old ‘paradigm shift’ raising its head again.

These are the continuing propositions of Crosbie Fitch and his distributed systems approach to online games

Time for a Revolution

Modern operating systems may be relatively straightforward to use, but under the surface they are now huge behemoths that require years of study and experience to administrate. Developing them requires huge amounts of manpower, which only the largest of organizations can afford.

It doesn't have to be this way. Just as the PC arose to avoid the costs of using, administrating and developing mainframes, a new operating system will arise that avoids the costs associated with the current crop.

In pursuit of this utopian OS let's go back to first principles, but this time we'll embrace the fact that all computers are networked together. We'll also decide that the primary purpose of all these connected computers is to allow the creation and exploration of one or more virtual worlds. This is after all, what everyone spends their lives trying to do -isn't it? - thinking of how much better the world would be, if only…

	In pursuit of this utopian OS, let's go back to first principles.

More often than not, achieving a big change requires collaboration and vision. Today that vision may be conveyed by pictures, words, music, even models, and many other things besides. From a pragmatic perspective, we use computers to produce documents, send e-mails, and play games. From a higher perspective, we use computers to create and explore virtual worlds.

In effect, I'm suggesting that we move on from the document-centric paradigm, to a world-centric one. Documents are simply messages that make up a set of transactions between one world state and another. For example, in the virtual world of property and work, a sale consists of documents describing an item of property, proposing a sale, proposing a purchase, and confirming agreement. In one world the item belongs to Fred, and the money to Bill, and in the other world, it is vice versa. Messing about in a variety of different worlds is what we're all really doing, and if computers can help us do it more effectively, so much the better.

But, maybe I shouldn't waste too much of this column by waffling on about such philosophical issues, but get down to the nitty gritty of how you go about making computers world-centric - even if you're not quite ready to give up being document-centric just yet.

Making it Easy for Ourselves

If we're going to do this, how are we going to make things easy for ourselves? How are we going to produce a network operating system without the might of an organization such as Microsoft or IBM? The answer takes a leaf out of nature's book, saying "Sod perfection! We'll just go for 'mediocre' and lots of it," -- i.e. get a billion vaguely functional neurons, slap 'em together any old how and get coherence through parallel processing and redundancy. This has to be better than the alternative of buying half a dozen super-servers and waiting years for legions of coders to figure out how to write perfect software.

The next few sections touch on each of the areas that need to be addressed by a new cyberspace network operating system and list the ways in which we can make our lives easier -- and the final system more effective -- by throwing out difficult problems along the way.

Resource Scalability
Remember, Moore's law tells us that we don't have to worry about CPU or storage resources given that their growth will far exceed the growth in network performance - especially with the comparable growth in traffic expanding to consume bandwidth and so prevent much improvement in latency.

Therefore, if we make any preference for a resource, we make it in favor of communication. You need to be a real scrooge here.

Miserly Communication

There are big problems involved in designing large systems to operate across a network. It's not like a CPU data bus: perfectly synchronized and reliable. The big wide world is a different kettle of fish from a nice, neat, printed circuit board. Across the Internet, you don't know anything about how long a message takes to transmit, whether it'll actually get to its destination, and whether things will get better, worse or stay the same. It's a case of 'bung the letter in the mail and hope'. If you're lucky, you'll get a reply - sometime. Maybe.
You cannot approach systems development in the presence of such vagueness in the same way as you can approach it on a predictable and reliable PC. Unfortunately, people do. The attitude is that you put some higher level layers over the network that hide its unreliability, and then you can simply carry on developing systems as though everything was still perfect. This may not be much of a problem on local area networks, but with the Internet operating on a global scale, large systems simply grind to a halt if they refuse to accept less than 100% consistency.

But, still with that goal of perfection uppermost in their minds, system developers typically, can still only countenance lowering their requirements just enough to allow their large systems to tick over once more.

I'm saying, "No way man, just give it up. Throw the whole idea of consistency and integrity out of the window - you just ain't going to get anywhere until you let go!"
Instead, we just go for best effort. Don't get obsessive about perfection, but contrive a tendency for glitches to become inconsequential. Just like social engineering, don't rely upon people to operate like clockwork, but find a way to make their aggregated inclinations result in a desired behavior.

Minimize Communication
If network communication is such a problem, let's do as little of it as possible. The emphasis of course, being on 'as possible'. We still have to communicate, and every ounce of bandwidth will be precious. And don't think there'll ever be 'enough', because there'll always be a little more realism that can be added. Remember that no system can contain a model of itself to the same fidelity.

Predict
One way of avoiding communication is to predict as much as possible. We only transmit what can't be predicted. It's simply that there's not much point communicating something the recipient can work out for themselves (or something they already know).
In some cases we may be able to communicate corrections to predictions if we know the predictions that others will be making.

Keep network distance small
If latency tends to be worse the further apart computers are on the network, then we should prefer communication with neighbors. Of course, this means we need to measure latency to some extent and use that to determine how much of a neighbor they are.

Prioritize
If we have a limited amount of bandwidth, or there is any other limitation on communication then it makes sense to prioritize messages according to their importance, e.g. based on the value of the information and its need for timeliness.

No Guarantees
There's no such thing as a free guarantee. Guarantees always cost something. We just require that best effort is used. If we need anything further than that then we'll provide it ourselves. So we don't need guarantees for message delivery, message ordering, or message integrity. However, it would be nice to know if a received message is corrupt or not, and what its serial number is, if only to be able to collect some statistics that will give us an idea of how good communication is with a particular party.

Bandwidth is precious
Bandwidth is precious, so let's not waste it or cause bottlenecks in the system. We'll take pains to distribute knowledge and lines of communication so that no single computer becomes too much of a focus. We'll always transmit the highest level representations of state, and utilize compression techniques where appropriate.

For example, if a piece of geometry can be described in a concise manner, such as 'a chair', then it doesn't need to be sent as a 500K Max file. This assumes, of course, that the recipient knows what chairs are and can generate them itself.

So we always deal at as high a level as possible, reverting to lower level descriptions when time permits. Or in terms of prioritization, it's likely that it may often be useful to transmit low levels of detail at a higher priority than higher levels of detail for the same item.

________________________________________________________

Resource Prudence