Re: [ogpx] Decoupling simulation services from land for VWRAP scalability

Carlo Wood <carlo@alinoe.com> Mon, 22 March 2010 14:57 UTC

Return-Path: <carlo@alinoe.com>
X-Original-To: ogpx@core3.amsl.com
Delivered-To: ogpx@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 95C693A6A0B for <ogpx@core3.amsl.com>; Mon, 22 Mar 2010 07:57:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.012
X-Spam-Level: *
X-Spam-Status: No, score=1.012 tagged_above=-999 required=5 tests=[AWL=-1.288, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745]
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 oFQWmfsMBLNt for <ogpx@core3.amsl.com>; Mon, 22 Mar 2010 07:57:48 -0700 (PDT)
Received: from viefep20-int.chello.at (viefep20-int.chello.at [62.179.121.40]) by core3.amsl.com (Postfix) with ESMTP id 30F6E3A68CC for <ogpx@ietf.org>; Mon, 22 Mar 2010 07:57:35 -0700 (PDT)
Received: from edge04.upcmail.net ([192.168.13.239]) by viefep20-int.chello.at (InterMail vM.8.01.02.02 201-2260-120-106-20100312) with ESMTP id <20100322145752.ERBY5170.viefep20-int.chello.at@edge04.upcmail.net>; Mon, 22 Mar 2010 15:57:52 +0100
Received: from mail9.alinoe.com ([77.250.43.12]) by edge04.upcmail.net with edge id wExq1d06H0FlQed04Exryx; Mon, 22 Mar 2010 15:57:52 +0100
X-SourceIP: 77.250.43.12
Received: from carlo by mail9.alinoe.com with local (Exim 4.71) (envelope-from <carlo@alinoe.com>) id 1Ntj4g-0000B7-NC; Mon, 22 Mar 2010 15:57:50 +0100
Date: Mon, 22 Mar 2010 15:57:50 +0100
From: Carlo Wood <carlo@alinoe.com>
To: Morgaine <morgaine.dinova@googlemail.com>
Message-ID: <20100322145750.GA28284@alinoe.com>
References: <e0b04bba1003111033s6289daf7tc477fb1a4315085e@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <e0b04bba1003111033s6289daf7tc477fb1a4315085e@mail.gmail.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
X-Cloudmark-Analysis: v=1.1 cv=KBHyIoyMIRH440NzHl6uMYpbxJngTLC2P1JzLC/QbPg= c=1 sm=0 a=qfvHT4_tRdAA:10 a=38zWk6xDZSoA:10 a=kj9zAlcOel0A:10 a=BjFOTwK7AAAA:8 a=LsdfPJ6fVTpTooJPnlAA:9 a=718c20sLvGDn4WaHV10A:7 a=CcT7aYhXMMBVmFdkMPlD3epAhnUA:4 a=CjuIK1q_8ugA:10 a=bW3kdApBr58A:10 a=3BF2FS9EHCwj3ujt:21 a=FkFDGoKyyXPV4G0g:21 a=HpAAvcLHHh0Zw7uRqdWCyQ==:117
Cc: ogpx@ietf.org
Subject: Re: [ogpx] Decoupling simulation services from land for VWRAP scalability
X-BeenThere: ogpx@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Virtual World Region Agent Protocol - IETF working group <ogpx.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ogpx>, <mailto:ogpx-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ogpx>
List-Post: <mailto:ogpx@ietf.org>
List-Help: <mailto:ogpx-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ogpx>, <mailto:ogpx-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 22 Mar 2010 14:57:49 -0000

It is possible to move "policy" (like 'have to follow the rules of physics')
to the viewers, and enforce it based on statistics: Assume that most viewers
are the official implementation and react predictably, and simply let
the viewers 'vote' to establish who is breaking that policy.

For example, 6 avatars are in a room. 5 run approved viewers, one is using
a rogue viewer. The one with the rogue viewer walks through a wall. The
other 5 detect this and (automatically) inform the server that this viewer
broke the accepted policy. The server bans the rogue viewer. That leading
by itself to keeping the number of rogue viewers small and hence the
system working.

On Thu, Mar 11, 2010 at 06:33:41PM +0000, Morgaine wrote:
> MXP has "perfect scalability" proportional to the number of actors in a region,
> because it has no centralized simulation.  Instead it employs the notion of
> "participants" that each do their own simulation locally, plus central "hubs"
> which reflect or replicate the contribution of each participant to all other
> participants in the shared space.
>
> It should be noted that while MXP's hubs are
> conceptually a shared resource, they are stateless and hence present no
> practical barrier to achieving high scalability in the simulation.  (Limits to
> actual scaling imposed by network bandwidth continue to apply of course.)
> 
> Although MXP's local participant simulation is hugely scalable in this way, it
> clearly lacks an essential ingredient that we have come to expect of VWs,
> namely environmental simulation / physics in the shared space.

-- 
Carlo Wood <carlo@alinoe.com>