Idea of maintaining an Island state without running the Island all the time

Hello all.

  Must an Croquet Router have at least one client (an headless one if you will) to maintain the Croquet Island the Croquet Router is routing for? Yes.
  But does that client have to be running the Island all the time
  to keep the Islands state up to date? No

  Why not append to the Islands serialized state the incoming invokations of methods and their parameters in serialized form?

  And when the size of the serialized invokations reaches some predefine limit then:
  1. the Island can be instanced from its serialized form (excluding invokations)
  2. the invokations are then invoked on that Island instance
  3. then that Island instance is serialized and is now the up to date version of the Island with out the extra invokations.

  Or does Croquet do this already?

  I want your thoughts on this and please ask me if I need to clarify something in this post.
-Zarutian

Hi -

Croquet doesn't do that out of the box but it is a strategy that we have
considered on servers for load balancing. Basically, the ideas like you
say that the island doesn't have to run all the time in particular if
nobody requests its state. In this case, you can simply serialize it to
disk and keep it there until somebody needs it. To deal with incoming
messages, you can create a log of messages which are replayed the next
time somebody requests the island to keep it up to date.

Cheers,
   - Andreas

Zarutian wrote:

Let's go back to the turning sky box example.  Suppose we arrange for  
the island to stop executing when there is one "update skybox"  
message pending, and nothing else.  If it had continued to execute,  
then, upon receiving the first heartbeat scheduled for after the  
update message's scheduled time, the update would be executed. The  
execution would have put another "update skybox" message on the  
queue, and the whole mechanism repeats.  But since we're not  
executing messages in this scenario, we never get another update  
message. We never get an accumulation of a "certain limit" of pending  
messages.  It is only when we explicitly intervene and turn on  
message execution again, that we execute the first message, which  
causes a second, which causes a third, and so on until we have  
repeated the whole mechanism the usual number of times. The only  
difference in the delayed execution vs normal execution is that the  
the delayed machine turns as fast as the processor can execute,  
rather than pausing to wait for heartbeats as the "real time" machine  
does. (In the original scenario, I think you said the "server"  
participant would be headless, so we can leave rendering out of the  
story.)


On Aug 22, 2006, at 9:30 PM, Zarutian wrote:

> I assumed that Croquet Routers sent Tick messages to advance the  
> time in the Island and these messages got no special treatment when  
> they are serialized.

They might be special. There are two queues. One in the controller  
and one in the island. You'll have to look to see:
   1. if heartbeats never show up on the island queue. Why would  
they? They're just used to set the time to execute to.
and
   2. if only the island queue is part of the snapshot.

But regardless, I don't think this affects whether or not you can get  
what you want by simply turning off execution, nor whether you may  
need to halt/reset router time in order to be happy with getting what  
you want.

I see no reason why your proposal is infeasible.  However, what do  
you hope to gain by it?

The first 2 possibilities that popped into my head:
        1) If the world is large enough to take a significant time to  
snapshot, then you can reduce response latency to sync requests by  
having a recently-cached snapshot ready.  Is this really worth it?  
You'd have to profile it.  I suspect that the download time over DSL  
would dominate the snapshot time.
        2) Failure recovery... if your router crashes, you have a recent  
snapshot of the world to recover from.  This would be cool, but would  
require additional mechanisms beyond what you have described (at  
least to do automatically).

Were either of these what you had in mind?  Or are you thinking of  
other benefits?

Josh



On Aug 24, 2006, at 8:49 PM, Zarutian wrote: