From: broehl@sunee.uwaterloo.ca (Bernie Roehl)
Subject: SCI: The VR Net ("what happens where" revisited)
Originator: hlab@milton.u.washington.edu
Organization: University of Waterloo
Date: Tue, 18 Aug 1992 21:10:50 GMT



As several people have pointed out, we seem to be converging towards a
specification of some sort.  At this stage, I think we need to start
making some decisions as to what will be included in the spec (and
more importantly, what *won't* be included).

First off, let's think about what we need the specification for.  To
my way of thinking, the purpose of a standard is to allow people who
are developing software (and hardware, and systems) to work in
parallel with each other; so long as everybody sticks to the spec,
everything should interoperate without any problems.  This greatly
accelerates the development process.

In order to achieve this, we have to decide what software, hardware
and systems we're talking about.  What are the "component parts" of an
eventual virtual universe, and what standards do we need in order to
connect them?

Well, clearly we'll have "objects" (however we define them) that send
"messages" to each other -- that much we all agree on.  Some of those
objects will be "VR stations", possibly with HMDs and gloves and
whatnot to allow human beings in the physical world to control them.

We want the VR stations and the machines that host the objects to be
tied together by some kind of network, which in effect defines a VR
"universe".

So what we're basically doing here is defining a protocol for allowing
objects (including VR stations with users attached to them) to
communicate via the VR Net, exchanging information of various sorts.

Now, a lot of the recent discussion has focussed on the idea of
"routers"; I would say that's a really, really bad name for them.
They're not really routers at all; routers happen at a much lower,
network layer.

Instead of "routers" I would suggest "filters" or "front ends" or
"access points" that link VR stations (or object hosts) with the VR
Net.  So, the model we get looks something like this:

    object host        VR station        object host       ....
        |                   |                |
        |                   |                |
        |                   |                |
        |                   |                |
      VNAP                VNAP             VNAP
        |                   |                |
     +--+-------------------+----------------+----+
     |                                            |
     |                   VR Net                   |
     |                                            |
     +--------------------------------------------+

(Sorry about the ascii-matic, but a picture's worth 1k words)

The "VNAP" is the VR Net Access Point.  It's the "filter" or "router"
we've all been discussing.  In some ways it's sort of like a terminal
server or an X.25 PAD; it provides access to the net and hides the
net's internal details from the VR stations and object hosts.

The VNAPs also do intelligent filtering of information from the
virtual universe.  More likely than not, the VNAPs will be linked
together with a high-speed, low-burstiness network (in some
implementations, they may all be in the same room, or at least on the
same Ethernet; in others, they may all be processes running on some
monolithic machine).  As networks improve, the VNAPs could be linked
to each other by a WAN (but still high-speed, low-burstiness).

We can move the VNAPs "closer" to the user as the network used to link
them gets faster; eventually, the VNAPs may reside on the object hosts
themselves (once the network connections to the object hosts get fast
enough).

The links between the object hosts (including VR stations) and the
VNAPs will probably be (initially) low-speed, non-bursty channels.
I'm thinking V.32bis up into ISDN 'B' channels (in other words, 38.4
kbps to 64 kbps).

The details of what goes on in the box labelled "VR Net" are, I think,
irrelevant to the objects and the VR stations; the only thing object
hosts should care about is the protocol for talking to the VNAP.  That
way we can experiment with different implementations of the VR Net
(and internal structures for the VNAPs) while still allowing
development of VR stations and object hosts to proceed.

The specifics of how the VR Net is implemented are irrelevant.
Whether the underlying network technology is TCP/IP or something else
altogether shouldn't matter.  From the protocol standpoint, it's a
"black box".

Similarly, the specifics of how VNAPs work internally are irrelevant.
The question of whether to use nested regions, sparse matrices with
hashing, BSP trees, octtrees or whatever else is one that we don't
need to answer right now.  In fact, we may implement several different
solutions and discover experimentally which one works best.  Whatever
they use internally should work with all the existing VR stations and
object hosts.

There are several advantages to this scheme:

   - we don't need to make difficult decisions any earlier than necessary
   - development of VR stations and object hosts can proceed right away
   - new innovations in networking or smart filtering can be implemented later

So, the thing we need to look at is the protocol between object hosts
and a VNAP.  If we can define that protocol, people can start
implementing objects, VR stations, VNAPs, and (eventually) worlds.

Comments?

        Bernie Roehl, University of Waterloo Electrical Engineering Dept
        Mail: broehl@sunee.UWaterloo.ca
        BangPath: uunet!watmath!sunee!broehl
        Voice:  (519) 885-1211 x 2607 [work]
Newsgroups: sci.virtual-worlds