[mmox] A tentative top-down analysis

Jesrad <jesrad@gmail.com> Thu, 26 February 2009 15:34 UTC

Return-Path: <jesrad@gmail.com>
X-Original-To: mmox@core3.amsl.com
Delivered-To: mmox@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8DF9628C128 for <mmox@core3.amsl.com>; Thu, 26 Feb 2009 07:34:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.507
X-Spam-Level:
X-Spam-Status: No, score=-2.507 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UxxBNzQcxGCa for <mmox@core3.amsl.com>; Thu, 26 Feb 2009 07:34:10 -0800 (PST)
Received: from mail-fx0-f176.google.com (mail-fx0-f176.google.com [209.85.220.176]) by core3.amsl.com (Postfix) with ESMTP id 14C533A6BF6 for <mmox@ietf.org>; Thu, 26 Feb 2009 07:34:09 -0800 (PST)
Received: by fxm24 with SMTP id 24so572635fxm.37 for <mmox@ietf.org>; Thu, 26 Feb 2009 07:34:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=w+E4wgMZv4YSPQXNCez58WlVzqMZX6FZXpTUqHAppYM=; b=aSpvz2xs0PxwBIwKGPTyxncO4o3bEBF+3UrkyzumVOHW9k8UsiWVzZI8tJJkJdNkZK mBjp/UuEHzpnvDvpvT3mu/ivNUXrAXOYjfYc7caPx7Pbq4UpLxpj2EHeWszGeiQJ19lJ C7cDzXcj3R7BUh5mCRr7HvMzNdGfzcY04KXIU=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=lgNLvl+dsMMAHU12jaNQ0H4Pu2gOztgROPGrYn3RzQ9CcDmhnyQGhwiN8snYuDRZLH S69EAcjcz2nlI8SPBwWh4NhPXXrZIJ8cl4F6Yz+LTZmLdeVXd/dklF7Hw5uLcnPiMmKI +FiGyBQNmpgc9fzuT1f9XbwFMx0lSUzPqUDMs=
MIME-Version: 1.0
Received: by 10.181.145.7 with SMTP id x7mr486482bkn.159.1235662470700; Thu, 26 Feb 2009 07:34:30 -0800 (PST)
Date: Thu, 26 Feb 2009 16:34:30 +0100
Message-ID: <53cd6c2e0902260734t7336df2dp2a97bd93b5db792b@mail.gmail.com>
From: Jesrad <jesrad@gmail.com>
To: "mmox@ietf.org" <mmox@ietf.org>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Subject: [mmox] A tentative top-down analysis
X-BeenThere: mmox@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Massively Multi-participant Online Games and Applications <mmox.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mmox>, <mailto:mmox-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmox>
List-Post: <mailto:mmox@ietf.org>
List-Help: <mailto:mmox-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmox>, <mailto:mmox-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 26 Feb 2009 15:34:11 -0000

As an answer to Catherine's call for more top-down views of the MMOX
project to complement the bottom-up approach, here is a collection of
thoughts on MMOX as viewed from afar:

What exactly, deep down to the bottom line, is the function that a VW executes ?

=> it establishes data links (or at the very least signals links to be
established) between virtual entities residing on a vast number of
networked machines so they can interact.

At the core, a VW is a ROUTER. A number of these special routers also
include their own "network endpoints" supporting entities specific to
the VW (like a combat stats database, an inventory server, etc.), for
specific forms of interaction, but as far as interoperability goes
these are particular cases of a more general layout (for example SL
residents may set up their own combat stats databases for other SL
residents to use, the case which will interest us later is whether
access to a VW combat stats server should be uniform across all
interoperable grids).

In the context of interoperability of grids, we must treat each grid
itself as a node of a relatively small P2P network. There is no
"supergrid" nor any central "interoperability to go" service for
existing grids to plug into as registered clients, nor will the be in
any foreseeable future. Thus, the interoperability protocol has to be
a decentralized protocol.

(this means it will need decentralized discovery, for one, since we
probably do not want to limit the protocol to hand-coded, static
cross-grid links)

The routing mechanism of this protocol is dictated by the inner
routing that the VWs realize on their own inner network. In many cases
a Virtual World mimicks functions of the real world in the way it
opens and destroys links between entities, for example entities each
have a location in the virtual world, and if two entities have
locations that are close enough then a link of "mutual presence" is
opened between them (whether this "presence routing" is done centrally
or is distributed has no impact at the interoperability level, since
centralized VWs will use a central gateway while P2P VWs will
implement it in the nodes - only the MMOX endpoints change here). This
is the minimal interaction which is universal to all "worldy"
entities. There are other forms of interaction that not all entities
are capable of, like collision, chat, left-mouse click, edition
request or Fire Magic attack, and the set differs between VWs.

(because it extends this mechanism, the interoperability protocol has
to transport the universal, common interaction "routing" services like
this "mutual presence": it must provide the necessary signalling for
opening and closing down relevant links between the entities across
grids - and though that sounds a very pedantic way of stating the
obvious it still goes better with actually saying it)

VWs also have non-realistic mechanism of establishing routes/links
between entities: entire kinds of interaction are disconnected from
the consideration of world "physical" presence. Instant messaging and
other forms of real-time, synchronous or asynchronous communication
(be it IM, monetary transfer or VoIP streams) between entities are
social-based instead of geography-based.

(this fully justifies the decision to split Agent and Region domains,
so that forms of interaction based on presence don't get mixed up with
interaction forms based on social ties: each kind follows a different
routing model. So far I see no other domains than these two, but then
maybe Delivery could be one if MMOX also defines the exchange or
push-through of content, identity and money between grids - that would
make HyperGrid the first example of a Delivery Domain service)

Of course, there needs to be some way to distinguish between the
entities that constitute a VW in order to address them at the MMOX
level and authenticate/accept their transmissions. For those entities
that represent people (us invaders from meat space) this implies a
general identity authentication system. That one was a given already,
but it's worth mentioning here because it fits as a particular case of
a wider mechanism that also identifies all the other (non-meat space)
entities of the VW: this consideration should remain in our minds when
we discuss OpenID, OAuth and other schemes - servers/objects/Scripts
may want to chat/transfer inventory/animate objects cross-grid, too !

To sum up so far, if I'm not mistaken:
- MMOX is a decentralized P2P routing protocol with automatic
discovery and at least two different routing schemes for Agent/social
and Region/geo domains of interaction, and possibly a third for
Delivery/Exchange,
- the routes established by the MMOX protocol will tunnel the VW's
services encapsulated in MMOX datagrams through the grids' limits
(whatever the centralization/distribution of those services inside
each grid, which only changes the endpoints)
- MMOX datagrams address specific entities of specific grids in a
uniform way (with auth) so significant work is needed to come up with
a good common denominator of an addressing scheme, that works well
with the discovery service(s) retained
- PDUs of Region/geo services are transported to all the relevant
entities that are mutually present (hence the seperate routing
scheme), while PDUs of Agent/social services are routed according to
specific social info (groups, etc.) and PDUs of other domains
(Delivery ?) are treated in yet another way.

Question: do each domain (Agent, Region, Delivery) requires its own
distinct discovery service ? I tend to think yes, but I'm unsure and
confused.