DEV Community

Cover image for Krestianstvo Electric Lazy Reflector for Croquet VM
Nikolay Suslov
Nikolay Suslov

Posted on • Updated on

Krestianstvo Electric Lazy Reflector for Croquet VM

Krestianstvo Electric introduces the Lazy Reflector for Croquet VM. This becomes possible due to implementing it in Clojure Electric programming architecture involving continuous-time signals with lazy sampling and streaming DAGs.

Lazy Reflector

All known Croquet implementations (including the Smalltalk, VWF, Croquet OS and recent Multisynq protocol) also OSS Krestianstvo on Solid JS are involving discrete timestamp generator (aka Reflector server). The Reflector should produces periodic ticks (~25-50 ms) and also timestamps all external messages coming from the views, then replicates these messages back to all connected peers of some concrete session (Island). If Reflector will not produce any messages, the Croquet VM will be suspended, waiting for any. In simple words, Reflector periodic ticks are needed for any animated in time simulation go forward in Croquet. But, the high frequency Reflector becomes redundant for simulations with slow rates for example or in the applications with no time-animated simulations at all.

The Lazy Reflector is "ticking" and "time-stamping" only on demand, staying the most time idle and laziness - not producing any work at all! However it guarantees, that all connected peers will get just the same ticks and time stamped messages, without missing a single one! As it is based on backpressured Electric continuous lazy server clock.

(new (actQueue (reset! !reflectorTime (e/server e/system-time-ms))))
Enter fullscreen mode Exit fullscreen mode

That perfectly fits Croquet architecture, as in general the most application work is done locally by the clients themselves. That includes involving Future messages with temporal recursion that producing no network traffic at all (future messages never going to the Reflector).

Also Lazy Reflector ticks are now not added to the Croquet VM priority queue. They are only moving local virtual time forward, pulling lazy server clock on demand by the future messages.

Past & Present Virtual Time

To try it in action, there are several example applications in Krestianstvo Electric.
Want to mention, that in the Counter example, the button "Loop" is not triggering Reflector to start ticking periodically. The button send only one external message launching temporal recursion on all connected peers. Then future messages pull the lazy server clock with the sample rate defined in the future step amount (after every virtual 0.5 sec in future do :step).

step (fn [m]
    (swap! !objData update-in [seloID objID :x] inc)
    (sendFutureMsg {:name :step, :when 0.5, :objid objID}))
Enter fullscreen mode Exit fullscreen mode

The source code is available on Github repository

Top comments (0)