Re:WiscWorlds app

On Jul 7, 2006, at 7:22 AM, David Faught wrote:

> Hi Howard,
>
> I finally had a chance to try out your new app last night, but it
> wouldn't work for me.  I have a reasonably good cable connection
> through TimeWarner and the PC is wired, the same one that I have used
> to Croquet-connect (once, a few weeks ago) to Peter Moore's island at
> UMN.  I tried a couple of different times at around 7:30 and 9:30 PM
> and waited several minutes each time, but all I ever got was the big
> red neverending rectangle.

Try again. It looks like the machine running the router (and a bunch  
of other stuff on campus) was rebooted last night.
It happens, and we don't have things set to automatically restart  
when the machine goes down.

For debugging purposes, please see the thread "Running Wisconsin  
Croquet Demo" (e.g., from me July 6).
Also, this:
On Jul 4, 2006, at 9:51 AM, Howard Stearns wrote:
> Subject: Re: Video Conferencing
> To: [hidden email]
> If you go into the 'Wisconsinization' project, there are a number  
> of buttons.  The one marked '3dWiki' is the same as the button on  
> the startup project, and connects to a router on Mac which also has  
> a headless peer on Windows connected to it (to provide the current  
> world definitions).  The one marked 'campus' connects to a router  
> and headless peer both running in the same Squeak, on Linux.

Neither of these will be up permanently, but the 'campus' router is  
the one likely to go away first.

>   After waiting, I interrupted
> Croquet/Squeak and the traceback looked like it was waiting to logon
> to the global cache with some hardcoded ID, not "everyone".  I take it
> that this is a separate thing from joining the island?

yes. Explained below.

>
> On a different tack, by taking this approach to having persistent
> content, aren't you going a step backwards to a client-server model?

No. And yes. It depends.

We're all pretty used to the components of the client-server model,  
and we know what the issues are.
I think most folks individually have a some idea of what "full"  
TeaTime might be like. (I'm imagining a fully P2P overlay network,  
which carries traffic within and between islands.)
But the 1.0 SDK, aka Hedgehog, aka "Simplified TeaTime", is something  
in between.

If we parse it like a lawyer, here are the fragments:

- There's a router. The Internet is dependent on the workings of  
hardware routers. Here's a software router. We can make it  
arbitrarily reliable in a conventional sense, and of quite small  
scope for scalability, but it is still a single point of failure and  
not infinitely scalable.  It's easy, though to envision adding a fail-
over mechanism for reliability, and __maybe__ some sort of of Paxos-
like mechanism to make it distributed.

- There's something to give continuity of island state. This is  
simply a peer that is left on. There's some engineering involved in  
figuring out the "best" way to do this for a given application, but a  
"continuity server" is an easy and adequate model for now.

- There's a lot of immutable stuff that doesn't need to be in the  
island state. In the SDK, this includes textures, and comes first  
from your disk cache, otherwise you ask the router for a peer in the  
same world to give it to you. In WiscWorlds, we're moving more stuff  
into this cache. Sounds, movies, hopefully meshes. Right now, we have  
a global cache (among all our worlds) that is handled by an  
additional router. Everyone connects to it as a client, and one or  
more machines connect as a "server," analogous to the continuity  
server. This is what you saw being logged into with a hardcoded id.  
(Hats off to Josh for this model and implementation.) A WorldBase  
would be another approach. Both of these approaches do introduce  
another client-server-like single point of failure within this aspect  
of the system. However, I think it's pretty straightforward (e.g.,  
"just work") to swap this whole thing out with a "conventional"  
Distributed Hash Table p2p overlay network.

- Discovery of routers. The SDK handles this only on the LAN.  
Dormouse used a single global introducer. But it is pretty easy to  
envision a distributed introducer. In WiscWorlds, we ignore the  
problem by hardcoding the router (actually, the dispatcher) address.

The point is that we're trying to break the problems apart into more  
tractable pieces. Right now, the total effect for practical purposes  
is to still be be pretty dependent on "servers."  But I am 100%  
confident of being able to make everything "parallel distributed"  
when required -- except for the routers. Here I am only confident of  
making each router "serially distributed" (e.g., handling failover,  
but not automatically distributing a load using parallelism).  My gut  
feeling is that it is too early, and entirely unnecessary, to place  
bets on whether it is more productive to work on a parallel  
distributed router for simplified teatime, or to just work on full  
teatime.  But I am going to do neither. Just apps and the technology  
for them.

> Maybe for this application that makes sense, and I'm still trying to
> figure out what would be a good way to provide persistent content in a
> P2P model.  I guess UMN's approach is the WorldBase object store
> server.  Maybe by the time you provide a persistent but dynamically
> updateable object store and a meeting place/introducer server, you may
> as well have a full participating but unmanned host.

It should be clear that my preference is to break the issues apart,  
using individual solutions for orthogonal problems. To me, DHTs have  
the right math for immutable data/media, used across worlds, which  
never need to be garbage collected.  I think quasi-relational  
databases are a proven technology for handling metadata as a service:  
things like author, time, rating, comments, and postcard data all  
change slowly, and tend to be accessed in a way which allows a  
connectionless, service-oriented, big-iron server implementation to  
be adequate. In the long run, I'd like to see searchable metadata  
services handled in a more free way, but that's a political opinion,  
not an engineering one.