Some TeaTime Questions

Hi,

I'm new to the list and I've been playing with the Croquet demo. I'm interested
in the architecture of TeaTime and I've currently got a lot of questions about
that I haven't been able to answer via Internet searches. I have a Java / C++
background and I'm finding Smalltalk / Squeak to be a big hurdle at the moment.
If its ok I'll just dump a big list of questions in here and see how it goes.

1.) Does it contain support for replicating the code that implements the object?
In other words do all particpants have to have the same version of all the
software before they start or can this be sent over the network. For example,
to to deploy new code that didn't exist when the participants joined the
island.

2.) I read the architecture overview PDF and it talks about TeaTime having a
rollback / commit mechanism. I can't see anything about that in the beta
documentation though. I've assumed that the heartbeat messages from the router
are effectively implicit commits and there is no rollback. Am I correct to do
this?

3.) The need to specify when the execution will occur seems to create a
different API for replicated access compared to local access (effectively an
extra parameter). Most other RPC or object-broker systems don't have this
behaviour/requirement. This means people have to write code that knows about
TeaTime. Are there any problems with this?

4.) How would the system handle behaviour like game AI attached to an object? It
seemed to me that either this code would be running on all islands and they
would then fight for control of the object or it would be running only on one
which would create a single point of failure.

4b.) How about random factors in behaviour like game AI? As I see it there is no
global time reference so nothing that could be used to initialize random number
generators to the same state. Or is there? Are the fish in the demo for example
synchronized in position/movement across islands?

Sorry this is a lot of questions but I'm trying to work out if the TeaTime ideas
have more general applicability and also relate them to things I'm familiar
with.

Thanks in advance for any answers,

Martin

On Apr 30, 2006, at 3:13 AM, Martin Smith wrote:

There is no official support for adding new code as the system is  
running.  It has been talked
about as a feature, but I don't believe that it has been definitively  
placed in the roadmap.

That is correct.  The current version of TeaTime does not support  
rollback.

> 3.) The need to specify when the execution will occur seems to  
> create a
> different API for replicated access compared to local access  
> (effectively an
> extra parameter).

First of all, you don't NEED to specify a time in the future (using  
#future:), you can just
ask for the computatiojn to evaluated as soon as possible (using  
#future).

> Most other RPC or object-broker systems don't have this
> behaviour/requirement. This means people have to write code that  
> knows about
> TeaTime. Are there any problems with this?

Leaving aside the differences between TeaTime and RPC (eg: the latter  
is a communication
between exactly one sender and one receiver), I'm not sure in what  
cases you think that
programmers need to be aware of TeaTime, but would be able to remain  
unaware of RPC.
Because TeaTime supports pipelined, asynchronous messages,  
programmers have to think
less about the underlying infrastructure than they would for  
traditional synchronous RPC.
Does this address your question?  If not, could you be more specific?

>
> 4.) How would the system handle behaviour like game AI attached to  
> an object? It
> seemed to me that either this code would be running on all islands  
> and they
> would then fight for control of the object or it would be running  
> only on one
> which would create a single point of failure.
>

You could do it either way.  Computations that happen entirely within  
an Island (i.e. they do not
involve any message being sent across the island boundary) proceed  
deterministically, and
are replicated on all replicas of the island.  So, each replica of  
the AI object would compute the
same result, and cause the target object to take the same action.  
This would occur without any
network communication to coordinate the results of the AI  
computations (since only messages
sent across the island boundary are replicated).

> 4b.) How about random factors in behaviour like game AI? As I see  
> it there is no
> global time reference so nothing that could be used to initialize  
> random number
> generators to the same state. Or is there?

Yes...

> Are the fish in the demo for example
> synchronized in position/movement across islands?

... and yes :-)

If you need deterministic pseudo-random numbers, you can use
'Processor island randomStream next' or 'Processor activeIsland random'.
The former generates an integer, and the latter answers a random-
number generator that
generates floats between 0 and 1.

The fish use the latter.  You can see that Collection>>atRandom is  
called at several places
in the TDemoFish code.  #atRandom in turn calls #randomForPicking on  
its class, which calls
'Processor activeIsland random'.

(this seems a bit dangerous, since if the Collection class variable  
RandomForPicking is not nil,
then it is used instead of 'Processor activeIslandRandom'.  Since  
this global variable is shared
across islands, this would break determinism.  Uugh.  I just  
submitted a bug:
http://bugs.impara.de/view.php?id=3517 )

> Sorry this is a lot of questions but I'm trying to work out if the  
> TeaTime ideas
> have more general applicability and also relate them to things I'm  
> familiar
> with.

Hope this helps,
Josh


>
> Thanks in advance for any answers,
>
> Martin
>


----------
Joshua Gargus
Senior Croquet Developer, http://croquetproject.org
DoIT Academic Technology, http://www.wisc.edu/academictech
University of Wisconsin-Madison
1301 University Avenue, Madison, WI, USA 53715
608-265-9891

Would it be possible to leverage the "update from server" function to  
mimic the behavior  of dynamic code update? Such function would be  
important if we start to link up the to create a connected Croquet  
world to allow users to venture into a previous unknown island by  
loading the codes when the island is selected?

David

The problem is that there is currently one global namespace for  
code.  As long as you don't have namespace collisions/conflicts, you  
should be OK.  Of course, this assumes that the updates are applied  
at the same simulation time in each island replica, but luckily  
Croquet makes this easy.

Here's one way you might do such a thing (WARNING: we've not tested  
nor even tried this at Wisconsin.  Proceed at your own risk).

Make a class called IslandCompilerProxy, and define the following  
method in it:

class: aClass compile: codeString classified: categoryString
        aClass compileSilently: codeString classified: categoryString.

If the Island has an instance of the class, and you have a TFarRef to  
the instance, then you can cause all code to be compiled for all  
replicas:

aProxyFarRef future
                                class: TFrame
                                compile: 'moveUp     self translation: (self translation + (0@1@0))'
                                classified: 'movement'

Now that we have a concrete example, I'll again emphasize the  
potential for namespace collisions.   Say that you have two Islands A  
and B that make use of #moveUp.  If you decide that, in Island A,  
#moveUp should result in a translation of 2 units instead of 1, you  
can make this happen by sending the appropriate message to Island A's  
IslandCompilerProxy.  However, your locally running replica of Island  
B also has the new method, but other replicas of Island B still have  
the old version of #moveUp.  Synchronization is no longer guaranteed!

If you proceed with this fun but COMPLETELY UNSUPPORTED experiment,  
let us know how it goes.  It will be useful to develop some ideas  
about how to utilize this sort of functionality before a robust  
mechanism is developed to support it.

Best,
Josh


On Apr 30, 2006, at 1:20 PM, David Li wrote:

Joshua Gargus
Senior Croquet Developer, http://croquetproject.org
DoIT Academic Technology, http://www.wisc.edu/academictech
University of Wisconsin-Madison
1301 University Avenue, Madison, WI, USA 53715
608-265-9891

Hi Josh,

   I am new to Squeak. Speaking of global namespace, is there a  
convention used by the community to avoid this global namespace  
problem for codes? I think the problem of dynamically incorporating  
codes into the system have to do with

1. How the new codes are loaded?

2. How the new codes are named?

Adding new methods to existing classes and new classes to the system  
should not be a problem as long as a convention are followed.

The problem gets tricky when the existing methods of a existing class  
are redefined to different semantics such as your example: moveup  
gets change from 10 to 20 in two different worlds. However, I believe  
this could be solved with subclassing. Let's say Island A and B with  
two different physics: one on earth and one on move. When a player's  
avatar X entering from B from A, there are some attribute should be  
changed because of the environment. The fish example is a good one.  
Some attribute of X such as weight would changed, those the capacity  
of it is changed.

I think scenario like this is the best usage of the very late binding  
languages like Smalltalk being able to modify the running system  
dynamically. This would allow each island to be developed more  
independently and users to gain different experience going from one  
world to the next.

Any good pointers to the design of Squeak VM?

Thanks.

David


On May 1, 2006, at 4:18 AM, Joshua Gargus wrote:

> The problem is that there is currently one global namespace for  
> code.  As long as you don't have namespace collisions/conflicts,  
> you should be OK.  Of course, this assumes that the updates are  
> applied at the same simulation time in each island replica, but  
> luckily Croquet makes this easy.

On May 2, 2006, at 12:08 PM, David Li wrote:

> Hi Josh,
>
>   I am new to Squeak. Speaking of global namespace, is there a  
> convention used by the community to avoid this global namespace  
> problem for codes? I think the problem of dynamically incorporating  
> codes into the system have to do with
>

For new classes, just prefix them with something unique (eg:  
DLiObject, DLiMesh).

> 1. How the new codes are loaded?

Traditionally, external code is loaded from changesets (.cs file) via  
the file browser.  More recently, Monticello has become popular as a  
version-control system for Squeak code.

Code is "loaded" every time you define a new class or accept a new  
method in a browser.  The browser window passes the textual source  
code to the Compiler class, which compiles it and stores it in the  
method dictionary of the appropriate class.

The compiler can also be invoked by other code, as in my last email  
on this topic.

> 2. How the new codes are named?
>

They are named however the person who wrote them named them.  I don't  
think I get the gist of your question.

> Adding new methods to existing classes and new classes to the  
> system should not be a problem as long as a convention are followed.

Right.

Sure, that works (for this particular example)

>
> I think scenario like this is the best usage of the very late  
> binding languages like Smalltalk being able to modify the running  
> system dynamically. This would allow each island to be developed  
> more independently and users to gain different experience going  
> from one world to the next.
>

It seems to me that in the scenario you describe, the islands aren't  
developed independently; both of them must support a common protocol  
for world attributes such as gravity.

> Any good pointers to the design of Squeak VM?

Sure.
Squeak-specific:
http://www.iam.unibe.ch/~ducasse/FreeBooks/CollectiveNBlueBook/ 
Rowledge-Final.pdf
The original Smalltalk-80 design is still relevant:
http://users.ipa.net/~dwighth/smalltalk/bluebook/bluebook_imp_toc.html

Why do you ask this?  It seems a bit disconnected from the previous  
discourse.

Josh


Joshua Gargus
Senior Croquet Developer, http://croquetproject.org
DoIT Academic Technology, http://www.wisc.edu/academictech
University of Wisconsin-Madison
1301 University Avenue, Madison, WI, USA 53715
608-265-9891