The Core Croquet model describes a complete independent simulation, in which changing behavior is automatically synchronized between all participants. The model is best thought of as describing replicated objects with behavior over time, rather than as older models of program and data (or state). The collection of objects in a given replicated simulation is called an “island.”
However, one of the nice things about the Croquet model is that it can co-exist with other models. It is perfectly reasonable to use a “data” model for immutable objects (which do not change their behavior over time).
For example, the original Hedgehog design represents images (textures) as immutable data outside the island. Only a smaller low-resolution thumbnail sketch of an image is included in the island itself. A separate asynchronous mechanism brings in the high-resolution image data and makes it available to the rendering mechanism. This is done in a priority load order based on what is visible and the 3D distance between observer and image. The effect is similar to that seen on some Web pages where a page loads fairly quickly and then the various images “sharpen” as you watch.
Any mechanism could be used for fetching this non-Island data. But since Croquet already has a secure channel for sending messages, we use the existing participant/router connection. Messages are defined to request a (high-resolution) resource, which is then provided by some participant that already has it. The client software caches these – remember that they are immutable – and only requests the resource when needed. Once cached, the resource is available for any island that the user is participating in. Resources are named by the secure hash code of their contents, so it doesn’t matter if they are called different names in different islands.
The KAT generalizes this mechanism to store other immutable media, currently including .mp3 sounds and .mpeg video. These resources have a lot of bits, so moving them outside the island definition means that joining a simulation with media can be much quicker. We have also begun some redesign so that geometry can be represented off-island, too.
The KAT also uses a separate channel for this off-island immutable data. This allows all islands to use the same “global media cache manager” for all their immutable resources. It has been convenient during development to continue using the ordinary Croquet router mechanism. Participants join the global media cache just like any other “island”, but “synchronizing” is a no-op. There is no need to get the entire contents of all media, and so there is no actual island. However, like other “islands”, this “meta island” still has a single well-known router to connect to, and has secure messages defined to obtain resources. It also has an eager “push” mechanism to make sure that the global cache gets a copy of resources that people dynamically add to any of the participating real islands.
Independently of Croquet, other mechanisms are being developed for scalably handling a truly global-scale cache of immutable content-addressed data. (Distributed Hash Tables.) While the current “Simplified Tea Time” model of Croquet requires a reliable-delivery open connection (TCP) to a single router per island, these mechanisms allow a wide variety of optimizations based on the “timelessness” of the data. It should be possible to keep islands quite small (wrt size of data to be synchronized on joining), while at the same time making use of nearby participating machines to “keep your pipe full” when getting lots of different resources without any one machine or leg of the network being a bottleneck. In short, getting immutable media should be much faster. When combined with the idea of breaking large resources into smaller (still content-addressable) chunks, this is essentially what BitTorrent does. Such a network for media could be used by non-Croquet applications, too.
All of which is a nice example of how the OpenCroquet model allows a nice mix of the right technologies for the job.
