[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.
- [mmox] A tentative top-down analysis Jesrad
- Re: [mmox] A tentative top-down analysis Morgaine
- Re: [mmox] A tentative top-down analysis Jon Watte
- Re: [mmox] A tentative top-down analysis Christian Scholz
- Re: [mmox] A tentative top-down analysis Jon Watte
- Re: [mmox] A tentative top-down analysis Christian Scholz