proj-oot-old-150618-ootMmoNotes1

"

Under the hood, Croquet is based on a protocol called TeaTime??, which keeps multiple servers in synch by the simple, expedient means of feeding all participants the same messages in the same order. Messages produced in response to these messages are assumed to be the same for all participants, whereas 'outside' inputs (like avatar movement) get distributed to all participants via a distributed TwoPhaseCommit? protocol. Thus, the routing for external messages serves also as the synchronization mechanism. Users late to the tea party can request a snapshot - including code - and will process all messages from the timestamp of that snapshot.

Messages are typically scheduled for delivery at so many milliseconds in 'the future', though one can schedule for 0 milliseconds in the future. These future-messages get placed in the global queue, which doubles as a TailRecursion? mechanism (since the stack won't grow too deep when recursing across time). There is something of a global time-message heartbeat provided by the router, which lets you know when it is time to run all messages with a timestamp earlier than the global heartbeat.

...

The use of TeaTime?? binds Croquet quite permanently to its implementation language, which must be fully deterministic (down to the bit level) across all versions. This can make some optimizations difficult. "

" Neither TeaTime?? nor Croquet nor Squeak is designed for security. This isn't a real problem unless your motivation is either (a) 'open' distributed worlds where untrusted strangers can join and participate, or (b) production of interesting games - which usually requires hiding some information from some participants. Point (a) can, fortunately, be mitigated a bit: you can save a world and restore it later. OpenCobalt?? has added a simple authentication mechanism that will at least keep unwanted users out of an island, though they still can do anything once they are in it.

The current model of world organization requires that individual worlds be single-threaded. This isn't too problematic, since one can scale by using multiple worlds instead of larger worlds, but it does limit the practical size (in terms of complexity) of any given world, and can introduce a challenge for other interesting applications (i.e. developing worlds that compose other worlds by inclusion, inheritance, or transformation). It also means each user must have the whole world, even if they only want part of one. "

"

Why is Open Cobalt built on Squeak?

...

late bound, message sending language....purely object-oriented system

...

Squeak's ability to keep the system running while testing and especially while making changes

...

generalized storage allocator and garbage collector that is not only efficient in real-time (so that animations and dynamic media of many kinds can be played while the garbage collector is collecting), but that allows reshaping of objects to be done safely.

...

Open Cobalt’s TeaTime? messaging framework works by running the same computation identically (replicated) on different nodes (necessary for very large scale collaborative systems). This turns out to be a major constraint in the modern programming languages arena as most languages and hardware are oriented towards running as fast as possible at the expense of deterministic computation.

An example of this kind of problem is in the floating point number system (FP). Modern 3D infrastructure such as OpenGL? and Direct3D relies heavily on FPs for position and other geometry information. Unfortunately the various platforms do not implement FP to the same accuracy or quality. This means that in a cross platform environment FP calculations will not have the same results and the replicated computations will diverge in state. Calculations could be done using exact math and converted, but at a significant performance hit. You also have to watch for optimizations that will cause the answer to diverge.

...

When we first set out to build Open Cobalt's underlying Croquet architecture, we intended to do it in Java. However, we had to abandon that approach because Java lacked needed meta facilities. Open Cobalt relies heavily on the Smalltalk meta system and accessible internals. For example, part of the Open Cobalt system is #future interface for sending messages into the replicated islands. It is an uncluttered interface that reads naturally. Now consider the issues of translating this into Java.

First, Java will not let you write a general "message interceptor pattern" which means you're going have to rewrite the sending sequence repeatedly in the calling section instead of the graceful encapsulation #future provides. Secondly, Java requires that you statically type everything, greatly increasing the complexity of marshaling and unmarshaling arguments and of the support code required. Now consider implementing a timed message queue; you'd have to write inner classes with serialization for any future message. All that effort, compared to the intuitive #future mechanism implemented in Smalltalk. "

---