sendFrame() implemented in LOOLWebSocket is thread safe, and also deals with
large messages - sends the "nextmessage: size=..." frame before the actual
large frame.
The problem this is attempting to solve was that when sending a large frame,
it was split to multiple packets. During that, another frame was sent from a
different thread; which lead to confusion, and the resulting frame was
corrupted (because it ended up composed from unrelated packets).
Change-Id: Ie85952e431b1cad2fdc6e3c64df8a444ea0ae971
With the help of clang-format.
For reference, the following command was used,
but not all changes were commited:
clang-format-3.9 -style='{BasedOnStyle: WebKit,
AlignAfterOpenBracket: Align,
AlwaysBreakAfterReturnType: None,
BreakBeforeBraces: Allman,
DerivePointerAlignment: 'true',
ExperimentalAutoDetectBinPacking: 'true',
IndentWrappedFunctionNames: 'true',
UseTab: Never}'
Change-Id: I0f7490c7ee38aeefeefcf9d5d4c3dab380cd63b8
Reviewed-on: https://gerrit.libreoffice.org/30416
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
Proper parsing of incoming messages and better
prefix matching is done, as well as slightly
better logging when we timeout or hit exceptions.
Change-Id: I11adbf24a5505f6cda4a18ba855898dc5f82e238
Reviewed-on: https://gerrit.libreoffice.org/30190
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
Produces a human-readable logging string describing a LOOL protocol
frame. To be used for re-factoring snippets of similar code that
sometimes print also the flags, sometimes pointlessly print the
(binary) contents of a CLOSE frame (as if it was text), etc.
It has always been the intent that getAbbreviatedMessage() is for
producing human-readbale nice output for logging purposes only. But
this has not been mentioned, so (naturally) the function has been
misused. Sigh.
Tokenizes a string and looks for the requested named parameter (in the
form name=value, like the other getToken* functions).
Also add a unit test for the getToken* functions.
A source file (.cpp) must include its own header first.
This insures that the header is self-contained and
doesn't depend on arbitrary (and accidental) includes
before it to compile.
Furthermore, system headers should go next, followed by
C then C++ headers, then libraries (Poco, etc) and, finally,
project headers come last.
This makes sure that headers and included in the same dependency
order to avoid side-effects. For example, Poco should never rely on
anything from our project in the same way that a C header should
never rely on anything in C++, Poco, or project headers.
Also, includes ought to be sorted where possible, to improve
readability and avoid accidental duplicates (of which there
were a few).
Change-Id: I62cc1343e4a091d69195e37ed659dba20cfcb1ef
Reviewed-on: https://gerrit.libreoffice.org/25262
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
To use such enums would be a mistake. It is quite enough to just use
the message tokens as strings. Duplicating them as enums will just
lead to the enums getting out of synch (as they already were). We
would also need functions to covert between the string and enum
forms. It seems to be hard enough to keep the messages documented in
protocol.txt.
Add a function to determine whether a client message indicates user
interaction. We need that distinction when deciding when to do an
automatic ("idle" or "auto") save of document being edited.
"Interaction" is a loose term, possibly what we actually want is to
see whether the user is actively doing an edit that changes the
contents of meta-data of the document.
The new function takes a map from keywords to integer values, and accepts
parameters in the form of either name=keyword, or for backward compatibility,
name='keyword'. Use it to parse the type parameter of the key, mouse,
selecttext and selectgraphic messages. This restricts the accepted keywords to
those actually valid for each message.
Works now for the trivial 'connect' test program. Still need to add
pre-spawning of a new child process as soon as an existing one from the pool
has been taking into use. And need to test with the actual JS client.
Add a new program, loadtest, that runs a requested number of client sessions
in parallel to a loolwsd server. A client session loads one of a list of test
documents, and does some operations on it.
Move the getTokenInteger() and getTokenString() functions out from LOOLSession
into a new namespace LOOLProtocol, as they are neeeded also in the loadtest
program.
Add, also in LOOLProtocol, functions to parse some of the messages from the
server. (In general that is done in client JavaScript code, of course; only
for testing purposes needed in C++ code.)
