Cyberspace? What is it?
-
Technology to facilitate network based entertainment (interactive or
passive) for massive audiences.
-
A way of enabling massive audiences to participate in the same virtual
world, by making each of their computers talk to each other.
-
A library of software routines that makes writing interactive
entertainment much easier.
-
A way of efficiently sharing a model of a virtual world or artificial
universe.
What’s so special?
Unique
Other solutions are traditional, server based
Servers linked by high bandwidth backbones model the universe
Participants’ computers are just client terminals
Expensive
Other distributed databases are inappropriate
Designed for a reliable applications environment
Not optimised for responsive intercommunication
Heavyweight
Designed for Global Networks
LAN solutions do not scale
Scalable
Can work on any network, whether direct modem-to-modem, LAN, cable-TV,
Internet or Radio networks.
Industrial Strength
No practical limit to size of universe or number of participants
Large universes, particularly ones participants can build in, will be
very appealing
The current technological limit of about 32 simultaneous participants
does not represent a ceiling in terms of market.
Fault tolerant
Expectation of unreliability at core of design
Most other comparable systems are concerned with integrity. This
system makes its absence a feature - by sacrificing integrity, the
database can be optimised for response time.
Can cope with the temperamental Internet
Will automatically cope with communication breakdown and fluctuations,
continuously reassigning links according to performance
Asynchronous
Unlike games such as Quake, is not held up by slowest participant.
Not upset by communications lag (though naturally, the game still has
to address this aspect).
Not just for interactive entertainment
A virtual film set
A better World Wide Web
An operating system with a global network for a computer
Transparent distribution of software
Co-operative development environment
Why use it above any other approach?
Competitive advantage
Efficient
Optimised for communicating relevant changes in scene according to
priority
Greater tolerance to limited bandwidth
Doesn’t require expensive high bandwidth infrastructure
Preferred by network & access providers
Allow wider user base
Scaleable
Extra hard disk resources automatically exploited
Multi-threading permits multi-processor ‘server’ type systems
Multi-threading also allows handling of simultaneous connections
Symmetric (same whatever the system - participant or server)
The middleware is the same for consoles as for ‘servers’.
Flexible
Automatic configuration according to response time and capacity of
neighbouring systems
Automatic load balancing of neighbouring nodes
Processing distributed according to ability and response time, e.g. a
slow PC will do little background computation itself but will obtain
results from a more capable system up the line.
Simple
Very small API to distributed database, consisting of a single
function.
Technology
Object Oriented
Easily extensible
Conceptually easy to handle
Active
Not only data is shared, but programs are too.
Products and upgrades may easily be distributed
Products can be developed even while on-line
Application rules independent of platform (only front end is written
for platform)
Distributed
Not reliant on one or a few servers.
Any system can go down without significant loss
Distributed processing as well as data
Transparent
Transparently replicates information
Authors can pretend there is just a single database
No need to worry about communications protocols, etc.
Authors just need to set priority attributes appropriately
Drawbacks
Investment
Risk
Reliance on success
New Technology, new skills
Not appropriate just for primitive Quake type games with few
participants over a LAN
If need is only for LAN or low latency Internet based games with up to
32 participants, another approach would be more cost effective in the
short term.
Quake type games over a LAN have a small and easily modelled universe
where the only elements of unpredictability are the human participants -
in such cases it is more efficient simply to communicate the
participants’ input.
Possibilities
Rapid production of online entertainment
Online entertainment development (in-house)
Online art production
Other group working
Competition
Various Internet oriented solutions based on enhancements to essentially
‘brute force’ approaches, e.g. high speed backbone and server.
Microsoft and Direct Play
US Military, Department of Defence, HLA/DIS
Sun et al and use of Java in a distributed object space
World wide web, VRML, and high end 3D participants.
As yet unannounced approaches
A similar approach
Other Questions
Is it truly feasible?
Designed with the much higher volume of data transfer
needed by true VR applications rather than 3D maze games like Quake which
have static universes.
We know how to ‘brute force’ replicate databases around the
network, this is fairly straightforward to do, the only complications
arising from simultaneous access to the database.
Current distributed object oriented environments (even active ones) do
exist but all presume that reliability is the primary concern.
For VR the overriding importance is response time, particularly for
interacting participants. Our approach is entirely optimised towards this
and is designed to ‘not care’ that low priority events may be missed,
at the expense of high priority events.
How does it work - simply?
It is a local database where changes to data cause messages notifying
these changes to be sent to a parent database and any other subscribing
databases.
It is a self organising hierarchy of peer-to-peer systems in which
systems are both clients and servers, some being heavily biased one way or
another.
Self organising hierarchy in the sense that relationships can change
from one minute to the next depending upon the availability of a system
(network traffic), the data it contains, and its capacity and performance.
Peer-to-peer in the sense that no system is inherently a client or a
server, and that in spite of capability each system is considered equal in
importance.
Client in the sense that a system can subscribe to information held by
another, and server in the sense that a system can support many
subscribers.
|