Also clear its input buffer explicitly.
Change-Id: I8badbb96d98eaf10433a65fcfd13b0d6d5893594
Signed-off-by: Ashod Nakashian <ashod.nakashian@collabora.co.uk>
Ignore input in a somewhat gentler way.
Signed-off-by: Michael Meeks <michael.meeks@collabora.com>
Change-Id: I758302dc3bb1aa87f9fbfa726f73f4b9339e08c2
...Thread.
Conflicts:
net/Socket.hpp
net/SslSocket.hpp
Signed-off-by: Dennis Francis <dennis.francis@collabora.com>
Change-Id: I92b8f4b52e7bd60b69305c1916eed8a14a4c1560
Avoiding default values for parameters makes the code easier to read.
Especially true for bool parameters. But sure, just a question of
taste.
Change-Id: I473f70bdfafe3a9ccfb325def8760d78fee7e9a6
Signed-off-by: Tor Lillqvist <tml@collabora.com>
When writing to the socket, it's always more efficient
to fill the buffer up to the hardware limit for each
write. This is doubly important for efficiency with
SSL, due to the overhead of encrypting multiple
small buffers instead of one large one.
Currently we don't write more than one message
at a time, primarily due to limitations in
the Poco sockets in the unit-tests, which
have a hard time consuming multiple WS frames
with a single poll (subsequent calls to poll
doesn't enter signalled state until new data
arrives, possibly because the data is read and
buffered internally, making the whole scheme
of using poll unreliable and meaningless).
Change-Id: Ic2e2cf1babfb5ab4116efd93f392977ba234d92b
Signed-off-by: Ashod Nakashian <ashod.nakashian@collabora.co.uk>
Now that the WebSocket functionality is available in
WebSocketHandler, we can cleanup Socket.
Change-Id: Ia3703ab5a2f00fb835eb80493bc400a91dabefad
Signed-off-by: Ashod Nakashian <ashod.nakashian@collabora.co.uk>
A utility class to create a WebSocket connection based
on WebSocketHandler, http::Request, and SocketPoll.
Change-Id: I00dfd6fc88e210860e0e378587ef1c0a0a65bb5c
Signed-off-by: Ashod Nakashian <ashod.nakashian@collabora.co.uk>
This adds support to Web-Socket upgrade handshake
validation. We never had a proper client-side
Web-Socket, so never needed this.
Change-Id: If4b8e42daeab13a430179128750f6a4f17452f28
Signed-off-by: Ashod Nakashian <ashod.nakashian@collabora.co.uk>
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>
