This simply reduces the public surface area
of the WebSocketHandler class.
Change-Id: I93be58923f429bceab74a9e239ad0fad11390449
Signed-off-by: Ashod Nakashian <ashod.nakashian@collabora.co.uk>
Normally writeOutgoingData flushes all the available
write buffer to the socket. However, when an error
occures during the write, the flushing loop is
broken and the error is expected to be handled
in the poll loop (or, at any rate, the poll loop
will sooner or later retry).
This doesn't work when the socket is being shut
down. Details and stack-trace is added in the
code to document this scenario.
The proper fix to flushing before shutting
down is to do it asynchronously (i.e. flag for
shutdown, let poll flush the buffers, and then
close the socket), but currently this isn't
easily possible (again, details in the added
comment). For now, we do a second attempt to
write, before we give up and warn of lost data.
Worth noting that this was caught thanks to the
simulated socket error logic. Every so often the
Close Frame of the WebSocket was getting lost.
This frame is asserted in the 'crash test' and
the explanation is that it happened when the
simulated socket error happened to hit during
the writing of the Close Frame (as one statistic
this happened ~15% of the time, when running the
crash test in a loop). With the retrying in this
patch I was able to run the crash test successfully
a few 100 times without failures.
Finally, we unify the flushing with the mobile-app case
to minimize the differences as much as possible and
improved the logging a bit.
Change-Id: I0c0559d6095cd2af8250a7e65a972ba672ecd4b1
Signed-off-by: Ashod Nakashian <ashod.nakashian@collabora.co.uk>
For large transfers eg. image previews, particularly with SSL's
protocol limit of 16k byte blocks, we see lots of inefficiency
repeatedly copying a 20Mb image and shuffling it down a
std::vector as we write data out.
Change-Id: I620568cad2e6f41684c35289b0ee77cf7f59c077
Signed-off-by: Michael Meeks <michael.meeks@collabora.com>
Per the rfc (https://tools.ietf.org/html/rfc6455#section-5.5.2):
"An endpoint MAY send a Ping frame any time after the connection
is established and before the connection is closed."
And "Upon receipt of a Ping frame, an endpoint MUST send a Pong
frame in response, unless it already received a Close frame."
Here we allow for pings to come from clients and we respond
to them by pongs, as required by rfc 6455.
Change-Id: I8e285f095526e4b67373ecb3ae1efc9c8717d756
Reviewed-on: https://gerrit.libreoffice.org/c/online/+/102948
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Andras Timar <andras.timar@collabora.com>
Sometimes multiple messages are processed in a single iteration
at socket level. This happens in WebSocketHandler and when draining
Document queue.Just covered these cases.
Change-Id: Ifa46f5d484b67015cca64008b2c89426cc839e64
Reviewed-on: https://gerrit.libreoffice.org/c/online/+/99387
Tested-by: Jenkins
Tested-by: Gabriel Masei <gabriel.masei@1and1.ro>
Reviewed-by: Michael Meeks <michael.meeks@collabora.com>
Reviewed-by: Gabriel Masei <gabriel.masei@1and1.ro>
The map._activate, among other actions, is sending indirectly some messages
to the server like clientzoom and clientvisiblearea. If these messages are send
before the document finishes processing the load message then there is
a chance that a nodocloaded error will be thrown because there is a
chance that the messages will be processed in parallel with load. This happens
constantly for xlsx files. This is generated by the Unipoll mechanism which,
in case of xlsx files, triggers a parallel processing.
To avoid the above scenario a mechanism of disabling parallel processing of
messages in kit was implemented and is used for load and save messages, for now.
Change-Id: I4c83e72e600f92d0bb4f1f18cebe694e326256d0
Reviewed-on: https://gerrit.libreoffice.org/c/online/+/98519
Tested-by: Jenkins
Tested-by: Michael Meeks <michael.meeks@collabora.com>
Reviewed-by: Michael Meeks <michael.meeks@collabora.com>
There aren't multiple processes that would need to "ping" each others.
Ifdef out the related member variables and code completely. Having
them partially in caused lots of FakeSocket polling with zero timeout
which is less than ideal.
Change-Id: Ibdfa4980d6d4fc9c00ea5146ca8d75ca0df81f1d
Reviewed-on: https://gerrit.libreoffice.org/c/online/+/97021
Tested-by: Jenkins
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Tor Lillqvist <tml@collabora.com>
More readable and typically more efficient.
Change-Id: I9bd5bfc91f4ac255bb8ae0987708fb8b56b398f8
Reviewed-on: https://gerrit.libreoffice.org/c/online/+/95285
Reviewed-by: Michael Meeks <michael.meeks@collabora.com>
Tested-by: Jenkins
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Sometimes kit process goes into a heavy processing state (or even hangs)
and is not able to report its memory usage. Thus we can't implement cleanup
of problematic kit processes based on memory information reported by kit.
By moving memory reporting to admin module we avoid this problem.
Change-Id: Icf274e3a3a97b33623a93f9d2dc1e640ad9b7d99
Reviewed-on: https://gerrit.libreoffice.org/c/online/+/92752
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Michael Meeks <michael.meeks@collabora.com>
Weak pointers can be null and must be
checked before using. This fixes at least
one segfault and prevents a number of others.
Also, minimizes locking of weak pointers
in the message handlers.
Change-Id: I306501c26c3441d7bd6812d51fa17e7356126f32
Reviewed-on: https://gerrit.libreoffice.org/c/online/+/92828
Reviewed-by: Michael Meeks <michael.meeks@collabora.com>
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
LibreOffice core uses that, too, and we support an even more
restricted set of compilers.
Change-Id: I0d0e2c8608e323eb5ef0f35ee8c46d02ab49a745
Reviewed-on: https://gerrit.libreoffice.org/c/online/+/92467
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Tor Lillqvist <tml@collabora.com>
This mends several problems from commit
5710c86323.
Change-Id: I1b29f29ca81679608a2692488fa1ef22b2e62dfd
Reviewed-on: https://gerrit.libreoffice.org/c/online/+/92032
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Michael Meeks <michael.meeks@collabora.com>
It took both an std::string and a length. Take a char* and a length
instead.
Change-Id: Id37dfa67fe1baae09b69819680848a0a8a1d80ed
Reviewed-on: https://gerrit.libreoffice.org/c/online/+/90552
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Essentially we want to be able to separate low-level socket code
for eg. TCP vs. UDS, from Protocol handling: eg. WebSocketHandler
and client sessions themselves which handle and send messages
which now implement the simple MessageHandlerInterface.
Some helpful renaming too:
s/SocketHandlerInterface/ProtocolHandlerInterface/
Change-Id: I58092b5e0b5792fda47498fb2c875851eada461d
Reviewed-on: https://gerrit.libreoffice.org/c/online/+/90138
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Michael Meeks <michael.meeks@collabora.com>
WebSocketHandler handles this complexity for us now, and for the
forseeable future. Simplify to prepare for larger re-factor.
Change-Id: I73b919885adc358cb6502a13492cdac85c34459c
Reviewed-on: https://gerrit.libreoffice.org/c/online/+/90059
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Michael Meeks <michael.meeks@collabora.com>
Happens with some close frames eg.
[ docbroker_001 ] TRC #21: Incoming WebSocket data of 6 bytes: 88 80 4a 2c 44 f9 | ..J,D.|
fin = true
OpCode is Close (= 0x8)
hasMask = true
payloadLen = 0
headerLen = 2 -> 6 after hasMask is taken into account.
Change-Id: I0e212e4589c3cc63db16f7065dc90cd0bd539ada
