The closing handshake.
Either peer can send a control frame with data containing
a specified control sequence to begin the closing handshake.
Upon receiving such a frame, the other peer sends a
Close frame in response, if it hasn't already sent one.
This is possible by moving all the password handling logic to
Document container class. When a user opens a password protected
document the first time, it saves all possible data such as
password, password type etc. Upon opening the same document
again, password is matched with the cached password saved in the
document container class before allowing the new view access to
this document.
Change-Id: Id1f2b6e06de806564bf865e83fed51b01c9a0fbc
Reviewed-on: https://gerrit.libreoffice.org/22208
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
When invalidating we need to rerender more tiles at once.
This change optimizes that with a new command which rerenders a
larger area once and then separates the rendered buffer into more
tiles. This generally decreases the invalidation time by 2-4 times
and in some cases (when invalidating images in document) up to 9
times.
ChildProcessSession class now moved to own files.
Change-Id: Ic67c8563ada51f23c83e06631ad913af610d395c
Reviewed-on: https://gerrit.libreoffice.org/20895
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Henry Castro <hcastro@collabora.com>
MasterProcessSession class now moved to own files.
Change-Id: Ic1a980295b9bb4b28ec9e205de1544fb98ad98f8
Reviewed-on: https://gerrit.libreoffice.org/20893
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Henry Castro <hcastro@collabora.com>
This is a single json that contains both load and rendering options.
Currently only the rendering ones are added to it by the client.
Also, just accept the options string for now, a later commit will have
to actually pass the rendering part to
lok::Document::initializeForRendering().
Introduce a bit of hierarchy there, at some stage we'll want to re-order the
tile requests a bit so that it works better for collaborative editing; for the
moment, removing the duplicate entries is enough.
When requested, the document is exported under
/jail_path/CHILD_ID/user/thedocument/RANDOMDIR/filename
and CHILD_ID, RANDOMDIR and the filename are communicated to the client.
When the client requests
http://server:port/CHILD_ID/RANDOMDIR/filename, the exported document
is served and then RANDOMDIR is removed
In Writer a part is a page and we only notify the client about the
current page in which the cursor is. Internally (invalidation and
caching) we work with a single part (0)
Implementing this Was harder than I first expected. The basic idea is as
follows: The master process puts each message arriving from a client that
isn't "canceltiles" into a (client-specific) queue. A separate thread that
pulls messages from the queue at its own pace and handles them as
before. Incoming "canceltiles" messages are handled specially, though: The
queue is emptied of "tile" messages.
The above sounds simple but there are several details that were a bit tricky
to get right.
Remove any intersecting cached tiles. It is the parent process that handles
the tile cache, so it must look for invalidatetiles: messages, too, before
passing them on to the client. To know for which part we should remove tiles,
add an "ephemeral" curpart: message that the child process sends to the parent
process before the invalidatetils: message.
Why did I wait so long to do this? This is obviously the right thing to do, I
hope, and has a very significant impact on the robustness of the server...
Just call the getStatus() function directly in the child process, which will
always cause a complete status: message to be sent to the client. No
documentsizechanged: messages now sent to the client at all.
It probably is not a good idea to keep depleting the entropy source needlessly
by having a separate RNG in the preSpawn(). Use just one shared RNG and
protect access to it with a mutex.
