A connect token is generated when the multiplayer canvas view is loaded, and this becomes the session's ID. The client must present this token when connecting to the canvas IO server, and it must match what was stored in Redis, not be expired, not already be claimed, etc.
If accepted, the socket session then stores the connect token to be used as a unique key that identifies that client session. Rate limits are implemented against this key using [rate-limiter-flexible](https://www.npmjs.com/package/rate-limiter-flexible), such as how often a `setpixel` command can be received and processed.
If accepted, the socket session then stores the connect token to be used as a unique key that identifies that client session. Rate limits are implemented against this key using [rate-limiter-flexible](https://www.npmjs.com/package/rate-limiter-flexible), such as how often a `setpixel` command can be received and processed.
The client will then request the image from the server, which will respond with the raw image data of the in-memory bitmap. The client paints this to it's canvas, then allows the client to request changes.
The client is free to send `setpixel` events as often as it likes, but the server will be configured with a rate limiter to limit the number of pixels that can be changed per client per unit of time. The default is 10 pixels per minute per client device. The client does not update the image in response to a mouse click. Instead, the client sends the change request to the server, and responds to messages from the server to update the image.
When a `setpixel` command is received, the in-memory image is altered and then everyone observing the image is informed of the update including the sender. This way, everyone observing an image receives the same state for the image, and everyone sees the same image.
