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>
UnitPrefork got what I assume is one of those PING frames that
ChildProcess::isAlive() sends before the actual reply when it sent the
"unit-memdump" message, and did not like it. Uncommenting the line
that outputs the "memory stats" message it expects showed:
Got memory stats 'PING'
Followed by:
Assertion `tokens.count() == 2' failed.
Fix by factoring out the handling of PING frames, PONG frames, and the
pseudo-PONG frames that we send ourselves in reply to PING frames into
a new function IoUtil::receiveFrame(). Use that in a couple of
places. (Probably should use in many more places.)
Getting past this then leads to later cppunit tests again being run,
and their failures then again showing up...
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.
SocketProcessor doesn't need to take response
instance, since by the time it is called we
are already upgraded to WebSocket and it's
too late to set a request-level status.
Change-Id: Id95087e60354a50148c88427130613356679cf82
Reviewed-on: https://gerrit.libreoffice.org/24110
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
