We need a fast and good (high avalanche properties)
hash function for the png caching to avoid collissions
(even in the very limited samples we have, since tiles
are likely to have patters, such as all 0's and all 1's
etc.).
Bob Jenkins's public domain SpookyV2 is used here.
It has great avalanache properties and is fast at
~3-bytes / cycle for large messages.
Only trailing whitespace was removed from original
sources and 4 tabs converted to spaces.
Change-Id: Ife57237321625c836d85c894d939fd04a8f577bb
Reviewed-on: https://gerrit.libreoffice.org/31292
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
The overall hit-rate improves significantly
when we don't remove entries too soon.
Here we give entries more time to show their
merrit.
There are now two limits, soft and hard.
The former is used to remove entries with no
hits at all, while the latter is used to
avoid overflowing the cache footprint too
much. Entries also get started with a single
hit, which prevents them getting evicted
too soon (i.e. right after getting added).
Finally, there is no longer need to reduce
the hit count of entries too agressively
since we have two tiers (soft and hard limits)
and zero-hit entries are removed before others.
The average cache size while auto-typing in
Writer doc is less than 180kb, which is 1.4x
the original size of 128kb.
Change-Id: I946318151638c9c64c714190084c492f9098852b
Reviewed-on: https://gerrit.libreoffice.org/31291
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
When receiving large messages the dynamic socket buffer
is resized to accomodate the incoming large message.
This buffer was previously never reduced in size.
This is an obvious leak that is now avoided.
When the buffer grows beyond quadruple the default
size, it is shrunk back to the default. This gives
a decent balance between memory waste and unnecessary
resizing up and down after each large message received.
Change-Id: Ic3996c80e96592af6f12c4abd1dd737bdc07b814
Reviewed-on: https://gerrit.libreoffice.org/31287
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
Messages larger than a certain size are preambled
with a 'nextmessage' message that hold the size
of the subsequent message.
This is a workaround to a limitation the Poco
WebSocket API where if the buffer size is
smaller than the received frame the socket
ends up in a bad state and must be closed.
Unfortunately the new API that avoids this
workaround is not yet released by Poco.
Here we minimize the need for 'nextmessage'
to truely large messages. The limit is now
raised from above 1KB to over 63KB.
We may raise this limit further, but that will
cost each socket that much dedicated buffer size.
Change-Id: I01e4c68cdbe67e413c04a9725152224a87ab8267
Reviewed-on: https://gerrit.libreoffice.org/31286
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
When IME is enabled and user presses the space button, firefox
sends 'compositionend' event with data = ' '. However, chrome
instead fires 'textInput'
event. Lets listen for 'textInput' event too and treat it like
'compositionend' event when data = ' '.
Change-Id: Icbebdf2e89f608f790e6ce68c49f474364e7d5ab
Parse the compositionend event's string, convert each into a char
code and pass them individually to server.
Change-Id: If79d538ccaebaa29749a5ca48a1f6ed5e0689ed5
Since Poco receiveFrame expected the buffer to be
at least as large as the frame, otherwise the socket
had to be closed, we sent a 'nextmessage' frame
before sending large frames with the payload size.
This caused many problems, not least related to threading
and lack of atomicity when sending large frames.
There is another API in Poco that doesn't have this
strict requirement, one that expects Poco::Buffer
and resizes it as necessary.
One potential issue is the possibility that a malicious
attacker might send very large frames to force the
server into allocating large buffers to read them,
thereby destibilizing the server, if not bringing it
down altogether.
Change-Id: I05014d54c3a1464f629ed82d761a7a65e4941985
Reviewed-on: https://gerrit.libreoffice.org/31184
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
tile and tilecombine have grown organically
and gained optional fields when originally
all fields were required.
Since internally we deduplicate them, we need
to compare the required fields and not the
optional ones. By moving all optional ones
after the landmark ver, we make comparison
easier and, hopefully, less error prone.
Change-Id: I309185d3e19a45c7d59bc872e8a76acd3c511c14
Reviewed-on: https://gerrit.libreoffice.org/31182
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
While some value of jitter is default in debug builds, one should
easily be able to disable this latency stuff using env. variables
LOOL_WS_DELAY=0 LOOL_WS_JITTER=0
Change-Id: I345df8f48adc69b5f237f18c981172441d21c757
Have a new event 'warn' which doesn't change the document
permission but just show the user dialog with some message.
Change-Id: I455168e4f7315acdcccfb31fc8c70b86bbc6caad
The new behavior is to warn the user when we try to save to
storage and set all the sessions of
the opened document to readonly, if storage server has no disk
space left. In case of WOPI, this is intimated by HTTP response code 413 -
request entity too large.
If save operation to storage failed due to reasons other than
413, just warn the user and let it continue editing the document.
We can add more reasons of failure and act accordingly in future.
Change-Id: I4b046fc38bbc0d752c89d90acb5991a958b76670
