whitebophir icon indicating copy to clipboard operation
whitebophir copied to clipboard

Group messages together instead of letting them get dropped

Open finnboeger opened this issue 5 years ago • 1 comments

If messages are attempted to be sent in too close proximity to each other instead group them and send them together. I also changed the pencil to get its minimum delay from the server settings. This introduces an issue if the delay is low and a user is e.g. attempting to fill out a shape and creating a long path to do so. The server will now happily pass along the changes to other connected clients but will not store it past a certain point (more precisely after MAX_CHILDREN).

How should we go about this? I see three possibilities:

  • We could obviously increase the default value for MAX_CHILDREN.
  • We could split the path and begin a new one when it exceeds MAX_CHILDREN, however this would circumvent the intention behind that setting.
  • We could stop the tool from drawing, giving the user some feedback.

I would go for the third option and add an entry to the wiki explaining that part of the configuration and recommending a higher MAX_CHILDREN value if a high MAX_TOOL_POLLING_FREQUENCY is set.

By opening a pull request, I certify that I hold the intellectual property of the code I am submitting, and I am granting the initial authors of WBO a perpetual, worldwide, non-exclusive, royalty-free, and irrevocable license to this code.

finnboeger avatar May 01 '20 22:05 finnboeger

I do agree that the current way we handle the load of messages is not ideal. However, I'm not sure grouping messages together over a single websocket message is the solution. There is certainly an overhead to decoding a message, but is it significant enough to justify that ? The initial goal of message dropping was to avoid overloading the server with too many messages, and to keep the size of boards manageable. Grouping messages together to send them as a single network message does not really help with either of these goals.

What we could do is:

  • handle message dropping at the board level instead of in individual tools, making it respect MAX_EMIT_COUNT and MAX_EMIT_COUNT_PERIOD
  • mark some messages, such as the first one and the last one in a shape as non-droppable,
  • simplify paths at creation time. This is more work to implement, but this would allow to both limit the server load and represent the drawn shape with higher fidelity.

lovasoa avatar May 09 '20 11:05 lovasoa