<div class="gmail_quote">On Fri, Dec 18, 2009 at 7:51 AM, Andreas Raab <span dir="ltr"><<a href="mailto:andreas.raab@gmx.de">andreas.raab@gmx.de</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
So, what about deadlines? Is there a way to set a deadline for a future send to be executed (after which your promise would yield some kind of timeout exception)? And, related to that, what about some provisions for rejecting messages (i.e. if a message queue has reached some maximum capacity or it is falling behing? How does Croquet handle such things (especially when it would have to be handled is such a way that guarantees identical results across replicated islands running on hardware with potentially very different characteristics)?<br>
</blockquote>
<br></div>
Croquet handles these issues as failures on the transport level, i.e., just like loosing the network connection. Also, for timeouts keep in mind the comment above (no timed inter-island futures) and that otherwise all Croquet time is simulation time anyway, that is the advance of time is determined by the flow of messages from the router. As a consequence, 'timeouts' that happen in island time are always replicated since it only depends on the sequence of messages. In practice we use this for example for detecting lack of presence indications from participants in Teleplace (you get a red exclamation mark next to the user if we've timed out the replicated heartbeat from that participant).</blockquote>
<div><br></div><div>Ok, I'm not sure I get all this...if there were three participants in a replicated island, are you saying that if for some reason a message cannot be delivered successfully to one participate (and I'm thinking specifically of the case where that participant is overloaded), that effectively that replica goes into some disconnected state? Presumably it would later re-sync state with one or more of the other islands once it recovers. However, I thought Croquet had some kind of a graceful degradation that wouldn't result in a less powerful machine being ejected outright. (btw, sorry that I'm asking these questions and haven't studied Croquet more closely, I've read the papers and played around with it a little, but haven't dug into the code much)</div>
<div><br></div><div>So...thinking about how Croquet might allow more graceful degradation: does Croquet enforce these strict requirements around successful queuing of messages to all replicas, but the replicated state effectively consists of just the model of the world and not any (or not a lot) of the objects involved in rendering the world? And, since most of the computational load would be in rendering, Croquet would, in fact, allow for a lot of degradation of the rendering and a participant would not get disconnected just because the rendering can't keep up with 30 fps? As long as the replicated island (consisting of just an abstract model of the world and not requiring a lot of computational load) is able to keep up with the message flow, the participant would remain connected?</div>
<div><br></div><div>Also, how does Croquet deal with really large worlds? Do you subdivide a large world into hectares or something (or the 3D equivalent of hectares...is there a word for that?) and do you just replicate the hectare the avatar currently resides in and the immediately adjacent hectares...and make the hectares sufficiently large that you would always have enough to render sufficiently far into the distance? What about objects that might sit on the boundary of multiple hectares?</div>
<div><br></div><div>- Stephen</div></div>