[vworld-tech] Ultimate MMO Platform

J C Lawrence claw at kanga.nu
Tue Apr 13 08:16:21 PDT 2004


On Mon, 12 Apr 2004 19:31:09 +0100 
Crosbie Fitch <crosbie at cyberspaceengineers.org> wrote:
> From: J C Lawrence

>> Trust need not be historical.  It can be pseudo-realtime through
>> sanity and cross-checks of current events.

> I don't really think that's trust though, I think that's just being
> 'well behaved'.

In what way is the following not a trust mechanic?

  NodeA receives a product from NodeB.  NodeA queries NodeC, NodeD, and
  NodeE on the correctness of the product from NodeB.  If they all reply
  that the product is reasonable, then NodeA accepts it.  If one demurs,
  then the product is refused.

The core element of "well behaved" is that the described item behaves in
an expected manner.  What is left out is how the veracity of that
expected behaviour is determined or what the expected behaviour is in
cases of error or fraud.  (single and double entry bookkeeping make a
decent parallel here).

> Trust is saying "I have noticed that my dealings with node X have been
> well behaved in all my previous dealings with node X, therefore I am
> prepared to risk more with node X than with other nodes that I have
> had fewer previous dealings with - (on the assumption there is only
> one node that can have the name X)".

Isn't_that/couldn't_that_be just a hinting layer injected into the
quorum mechanics?  Given sufficient volatility in the system it
approaches a random function.

> But (assuming addressability) you should be able to detect the same
> identity being used by two addresses.

Maybe, and only reliably to any extent if you either assume a central
core, or require that all nodes maintain full knowledge of the entire
population of nodes.  I've been assuming that both those models were in
direct contradiction to the peer-2-peer principle you wanted.

>> NodeA registers with identity X, and key Y and proceeds to use that
>> arrangement.  NodeB proceeds to also use identity X and key Y, but
>> doesn't register.  How do you detect this?

> Registration is made with the 'system'. 

Perhaps some definition is required here, both in terms of what the
"system" is, and what the propagation methods are for data across that
system.  My assumption has been that all nodes were first class nodes,
varying only by local physical resources and transient data spool
contents.

> If there is a dynamic hierarchy of responsibility...

Single root, multiple roots, ad-hoc roots, indeterminate roots, or lumpy
mesh?

> ... (which also passes word of identity), then existence of identities
> can be passed up this hierarchy such that sooner or later, if an
> identity is being used twice, it will collide with its doppelganger.

There are some implications there for cache retention and flushing which
you may not like.

> If NodeX is dealing with NodeB, NodeX can tell its parent "I'm dealing
> with identity X on address AddrB". If identity X has already
> registered on a different address then as this news passes up the
> hierarchy, eventually there'll be X on AddrA and X on AddrB.

> Naturally, if there is only one identity, it can make a well behaved
> change in its address if necessary (if behind NAT say). The anomaly
> occurs when there are two distinct entities simultaneously
> claiming/reporting the same identity.

How do you tell the difference? Who preserves the secrets/state, and is
that preservation reliable across unreliably connected/running nodes?

> The fact that false identity can generally only be detected when the
> identity is duplicated, means that either people leave their machines
> on all the time, or the identity code (public key) is invalidated on
> disconnect, and a new code generated on reconnect.

Which means keys have a half life or ungraceful disconnects are problem.

-- 
J C Lawrence
---------(*)                Satan, oscillate my metallic sonatas.
claw at kanga.nu               He lived as a devil, eh?
http://www.kanga.nu/~claw/  Evil is a name of a foeman, as I live.


More information about the vworld-tech mailing list