Features

Cyberspace in the 21st Century:
Stability Before Security, Part Six

Of course, the infrastructure's very interesting stuff and I'm sure many of you will want to get involved in one or more Open Source projects (middleware or otherwise) alongside producing games as an employee. Here's a link to some form letters that might help you transition your occupational status from employee to employee and Open Source worker: http://www.sage-au.org.au/osda. Some enlightened employers might even see key benefits to you working on Open Source projects as part of your employment.

I'm not simply saying, just develop the content to the games developer. What I'm saying specifically is wear two hats: one as a developer of proprietary games content, and the other as a developer of Open Source infrastructure. This way you get to do the same cool things as always, but you don't get confused into selling the technology in with the game. In any case, as long as you are paid the same, and get the same kudos, what's the difference? Oh, yeah…bye, bye technology licensing deals — crocodile tears to that.

And running away from big brother
The benefit of leaving the cyberspace platform to Open Source development is that you're one step closer to seeing who's really concerned about stability and security in cyberspace (pssst - it's the players). Well, ok, maybe it's obvious to some of you, but in my experience, it's usually been subsumed into the corporation's concern, i.e. the guys making the money.
Then it seems, people start forgetting what security is for. At best, you can hope for a patronizing, paternalistic care for the player, but topmost is probably a concern for protecting intellectual property, legal exposure, liability and litigation, etc. There's enough blame on games already for causing society's ills, so the last thing the games industry needs to add to its list of responsibilities is community policing (in the virtual world).

Speaking of which, I've always been surprised at how willing some chat services have been to take on the responsibility for ensuring that users behave themselves. Sure, there's 'value added' benefit in selling a chat service that's safe for the family (if that's a key market advantage), but if this gets extended via UO/AC/EQ into cyberspace then players are going to end up spending the bulk of their money paying to be policed - and much less on the entertainment (the fun bit). I'm not saying cyber—policing is a bad thing, or even that it's not going to become a lucrative business, just that, again, it's not exactly the raison d'être of games development.

Cyberspace will be as big as the Web. And just as policing the Web is a separate issue from developing content for it, the same will apply to cyberspace. For example, you might produce "Spaghetti Western World". One universe based on this theme could be un-policed. Another one could be policed. Why? To make sure players don't get up to any naughty business, like exchanging addresses for secret rendezvous, or details of cheap digital TV projectors — legit, honest guy. If you're looking for revenue models, perhaps in this case, it is that the un-policed version is free.

Not that Kind of Security
I haven't really been on an irrelevant diversion so far. When you realize that cyberspace will inevitably be developed by the Open Source community (or a compatible organization), then you'll have a much better perspective in terms of where the issues regarding stability and security are really coming from. They'll be entirely related to assuring the quality of the player's experience. The games developer will only need to worry about making sure their content tends to be entertaining, and figuring out a revenue model (joining the similarly worried ranks of musicians and movie moguls).

So there we are. I've removed all the games developer's stability and security worries in a few paragraphs. What a doddle eh?! Too fast for you?

Ok, so really, I've just passed the burden for the infrastructure of cyberspace onto the Open Source community, and cyber-policing onto society. You, however, now wear two hats: the first as a game developer for a respectable game development company, the second as an Open Source worker contributing to the development of cyberspace (when you get a break from helping your landlady carry out her garbage).

I'll be dealing with issues about producing content in a subsequent article - so put your first hat away for next time. The rest of this article requires the second hat (yeah, it might be red, at that).

Stability and Security
So what's next? Well, in previous articles we've looked at how it works and how it scales, but now it's time to look at how it keeps on working.

Continuing with the development of cyberspace as a distributed system of hierarchically related nodes, let's explore how we go about keeping such a system working, i.e. stable in the presence of failure and secure against attack.

As far as stability is concerned we'll first look at how we ensure the system remains stable and balanced in the absence of failure, but under arbitrary loading and stress, and second how we can ensure the system is not critically perturbed in the presence of expected failure.
Security is where we'll look at how the system can address unexpected failure and sabotage, at the application, system, and network levels, and still maintain stability and, in the case of sabotage, sustain minimal damage. However, although I thought I might be able to squeeze security into this article, I've simply run out of space, so you'll have to consider the next article as the second half of this one...sorry.

As I've indicated earlier, it's not critical to the system (or its ability to provide entertainment) that it addresses issues of player behavior (lawful, socially acceptable), data protection (privacy, intellectual property), and commercial viability (business and revenue models), and so this area will not be much explored in this or the next article. These issues may of course be addressed by anyone who wants to — perhaps if a commercial opportunity seems apparent?

Stability

A system is stable if it has the ability to maintain satisfactory operation (equilibrium) even in the face of destabilizing forces or events.

Some of the more obvious destabilizing things our distributed system has to put up with will be of the failure kind. However, there is also the workload aspect, i.e. stability in terms of load balancing across the various resources it uses: processing, storage, and bandwidth. Let's look at load balancing first. I've touched upon it in previous articles, but let's see if I can shed a little more light on load balancing here.

Load Balancing
We don't want the system to have undamped lurching or cycling of resource consumption between nodes or connections. Like two holiday resorts becoming alternately popular because while one has empty beaches and bargain prices, the other hasn't — and everyone decides to go to the other place next year.

Now, you can get yourself into all sorts of difficulties if you start making the load-balancing bit of a system too complicated because by being part of the system it has to address the complex behavior generated by its own complex balancing procedures. A bit of a Heisenberg idea here, i.e. an unbalanced system (without a load balancing component) may seem a doddle to balance, but once you introduce an extra balancing component, you no longer have the simple system that you started with. So, if you do address load balancing it's probably best to do it in a simple way and let PhD students burn their young brains out coming up with refinements (whether they add complexity or not).

So the approach I'd suggest is to use a heuristic approach, i.e. make some intelligent guesses, tweak it until it works and don't worry about why it works (unless someone pays you to find out). This is just like hacking, but with a veneer of scientific respectability.
We'll need heuristics for the organization of the relationships between nodes, responsibility for objects, and heuristics for utilizing local resources. There are probably a few others too, but we'll concentrate on the key ones.

Metrics
Many judgments between peers will need to be based on mutual experience. For that matter, any kind of decision often needs to be based on facts and figures. Our heuristics will likewise need to refer to a large body of measurements, statistics, and analyses thereof in making their decisions.

What are the sorts of things we need to measure, and what kinds of measurements are likely to be useful? We can quickly suggest the big three resources: storage, processing and communication. We'll be interested in qualitative aspects as well as quantitative ones — not just how much, but how good. The other things we need to measure will relate to the concepts that the system introduces, i.e. relationships, responsibility, interest, and objects.

I've quickly created a few tables (one to eight) to give an idea of the sort of measurements we might make in a distributed modeling system.

	Tables 1-4: Measurements Upon Storage, Measurements Upon Processing, Measurements Upon Communication, and Measurements Upon Relationships (NB Some of these measurements are made on each connection, with an aggregate measurement then also available).

	Tables 5-8: Measurements Upon Responsibility, Measurements Upon Interest, Measurements Upon Objects, Measurements Upon Reputation.

You may notice in tables one thru three that I've introduced the idea of integrity. Sounds like it could be useful as a security measure of some sort, doesn't it? Well, it can help towards that end, and when you see that an entirely new concept reputation appears in table 8, you might begin to realize its purpose. Well, I'll get on to that a bit later, but for now we just need to appreciate that a variety of measurements need to be made simply in order for the self-organizing nature of the system to operate. These measurements become the foundation upon which the heuristics are based. However, while we're talking about foundations, don't let that suggest you should take these measurements as cast in stone. There may be others that I haven't listed that may be more useful.

Of course, for entirely different purposes such as system monitoring, diagnostics, interesting statistics, etc. there's a myriad of other measurements that can be made,

______________________________________________________

Heuristics

join | contact us | advertise | write | my profile
news | features | companies | jobs | resumes | education | product guide | projects | store



Copyright © 2003 CMP Media LLC

privacy policy | terms of service