Time synchronization (and more) questions

I am a new user to Croquet, Cobalt and Squeak. My background is in programming
and game development.  Reading through the Croquet documentation, I had some
questions on time synchronization - my goal  in asking these questions is to
gain a better understanding of the Croquet system.

Thank you in advance for any clarification you can provide.

1) I'm an experienced programmer, game developer, and world builder.  I'm
interested in using Croquet for the creation of plant management/training
simulations (ie BioFuel plant management, Solar Power array management,
Geothermal plant management, and more).  Am I "barking up the wrong tree"
thinking that Croquet would be an excellent choice for a development platform?

2) I'm a little unclear on the use of externally-generated messages to manage
time on the server.  It would seem to me that using a heartbeat message would
easily create a situation where the pending command queue continues to grow
when heartbeats don't get through.  It would seem this architecture would
create a situation where adverse network conditions (for example under high
load) between server and router would be amplified by "processing spikes" on
the server when heartbeats do finally get through.  Perhaps I'm missing
something, though.

3) I'm not finding anything in the classes related to message-passing (so far -
haven't gotten through it all yet) that would indicate that messages include a
message length or a CRC32 value as a means to detect corrupted messages.  If
someone could point out the class(es) that hold this data, I would be much
obliged.  Also, at several points in the documentation it states that "messages
are never lost," but I'm unclear as to how this is accomplished.

Thanks again for your time and consideration.

-Darrel Cusey

[hidden email] wrote:
> 1) I'm an experienced programmer, game developer, and world builder.  I'm
> interested in using Croquet for the creation of plant management/training
> simulations (ie BioFuel plant management, Solar Power array management,
> Geothermal plant management, and more).  Am I "barking up the wrong tree"
> thinking that Croquet would be an excellent choice for a development platform?

I would think that too, but it'll take some time to get used to it.
Don't expect to ship a product by tomorrow or even a month from now.

> 2) I'm a little unclear on the use of externally-generated messages to manage
> time on the server.  It would seem to me that using a heartbeat message would
> easily create a situation where the pending command queue continues to grow
> when heartbeats don't get through.  It would seem this architecture would
> create a situation where adverse network conditions (for example under high
> load) between server and router would be amplified by "processing spikes" on
> the server when heartbeats do finally get through.  Perhaps I'm missing
> something, though.

This interpretation is incorrect. Heartbeats are sent from the router to
the clients (clients don't send heartbeats to the router) and only if no
other messages are currently in the queue. That's because there are
other messages those will carry the current timestamp and the heartbeat
only serves to produce artifical messages to make time progress if there
are no other messages currently.

Processing spikes can appear on the client though - it is quite common
when you have a temporary network problem to get lots of messages in a
short period of time. This is the reason why I usually refer to the time
model in Croquet as "stretchy real time". In a situation like you
describe, no Croquet time would pass while the network issue is going
on. Once it is resolved time will flow significantly faster than real
time until the client has caught up after which it will again proceed in
real-time. Modulo latency issues of course, but that's a different can
of worms ;-)

> 3) I'm not finding anything in the classes related to message-passing (so far -
> haven't gotten through it all yet) that would indicate that messages include a
> message length or a CRC32 value as a means to detect corrupted messages.  If
> someone could point out the class(es) that hold this data, I would be much
> obliged.  Also, at several points in the documentation it states that "messages
> are never lost," but I'm unclear as to how this is accomplished.

It's simply by definition. We use a reliable TCP connection and since we
don't drop messages in the code either messages simply don't get lost.
If the connection fails (the only case where you could conceivably loose
messages here) a full resynchronization happens, i.e., the entire state
is replicated from a peer.

For CRC and encryption, check out TMessageRelay>>sendDatagram: which
computes the CRC and encrypts the outgoing datagram. Its counterpart is
TMessageRelay>>runReaderProcess which reads a message, decrypts, and
verifies the CRC before delivering it.

Cheers,
   - Andreas