Re: Portals vs Links

Andrew C. Esh ([email protected])
Fri, 5 May 1995 09:07:14 -0500 (CDT)


On Fri, 5 May 1995, David Peck wrote:

> Then, under your model, the user of client A@T3 could make
> changes to his world (say, take the coffee off of the maker) which would be
> transfered to the server; unfortunately it takes almost 1 minute for this
> message to reach client [email protected]. Meanwhile, the user of client B decides
> it would be fun to smash the coffee pot (which to him remains on coffee
> maker) into tiny shards of glass, and he does so. His message gets sent
> back to the server. What happens then? The two versions of the same world
> are now inconsistent.

It seems to me that the server should be the only place where things
happen "live". If the faster link moves something, and the slower link
tries to act upon the object after it is moved, then the server will
receive the update from the faster link first. Whoever is first wins. You
snooze, you lose.

This will make using an interactive space through a slow link very
frustrating, but it frees the rest of the users from having to be slowed
down to the slowest common denominator. It also provides and incentive
for users to invest in speeding up their link.

It is possible to design a server so it has a token passing scheme, where
each browser is given the token, and the token is returned with that
browser's updates. Then all the browsers are sent (unreliably, and
unverified) the update to the server's space. The token can time out and
be regenerated by the server, too. This way, slower links can participate
more effectively, but the faster links have to wait for them.

Take your choice.

---
Andrew C. Esh                 mailto:[email protected]
Computer Network Technology   [email protected] (finger for PGP key)
6500 Wedgwood Road            612.550.8000 (main)
Maple Grove MN 55311          612.550.8229 (direct)
<A HREF="http://www.mtn.org/~andrewes">ACE Home Page</A>