EbitenCollablite is an Ebitengine based demo for using the Collablite sync server. This is cross platform and can be built for Windows, Mac and Linux.
EbitenCollablite (EC) is a graphical demo of the collablite project. A 10x10 grid of squares are displayed. Each EC instance is configured to generate random shades of red, green or blue. Every X milliseconds the instance generates a random colour of a random position and sends that change to the Collablite server. The server in turn will store and broadcast the change to all EC instances listening to a particular object id.
For example, if we run a single instance of EC configured to generate green shades, we may end up with this:
Now, if we run another instance configured to blue, we will get something like:
If we show the two instances side by side, we will see:
Note, the title of one of the windows is "green - test1" while the other is "blue - test1". This indicates that one is generating green shades for object test1, while the other is doing the same but with the colour blue.
There are a number of statistics shown on each instance. The ones mainly of interest are conflicts and CB (callbacks). Conflicts are the number of times that the client has had to discard an incoming change due to it conflicts with another change for the same grid location. In this case both instances have had 0 conflicts. The CB (callback) entry of 20.98 and 19.96 are the number of messages each instance has received from the server informing it of a change. Given both instances are generating approximately 10 changes a second, each instance receiving about 20 changes per second. Yes, an instance will still get a message from the server for its OWN change, due to it needs to get confirmation from the server that the change is good.
There is a quick youtube video showing the execution of the demo
There are a number of parameters to control how many instances, requests-per-second etc.
- host : Host and port of server. eg. "localhost:50051"
- objectID : Object ID that the client is working on. If you run different instances with different object IDs then they will NOT be sharing data.
- send : Should the instance generate traffic or just listen
- red/green/blue : Type of colours the instance should generate
- rps : How many updates per second. Maximum of 30
- loglevel : info/debug/warn/error
eg, when running the initial green instance shown earlier, the command was:
go run . -green -id test1 -rps 10 -host "localhost:50051" -send -loglevel debug
while the blue instance was
go run . -blue -id test1 -rps 10 -host "localhost:50051" -send -loglevel debug
To generate multiple clients easily, there is a powershell script run.ps1 (bash one to come soon) which have the following arguments:
- number of RGB instances to create. They are created in groups of 3 (one for each R,G and B).
- object id
- rps per instance
- host:port
For example,
run.ps1 10 test1 30 "localhost:50051"
will generate a total of 30 instances (10x3) all listening to object id "test1" while generating 30 updates/requests per second.
The server does NOT require many resources at all, and each EC client also requires very little. What DOES impact performance is the number of interrupts generated by the graphics library. Practically what this does is cause lag and DOES make the various instances become out of sync. They are all receiving the same changes but some are slower than others.
This is only if you start running LOTS of clients with high RPS on a single machine. Again, this is only for demo purposes... in reality the various clients will all be on different machines so this is not a real-world issue.