Matches the behaviour of real sockets in a real Online server better.
Seems to get rid of the occasional hang problem.
I had already some time ago suspected that such a change would fix
that problem, but unfortunately my first attempt missed one crucial
detail, so it didn't, and I spent days looking for other ways to fix
the problem instead, in vain.
Probably I should add some sanity limit on the number of buffered
messages, though... But if such a sanity limit then would be hit, most
likely much else is totally broken already anyway.
Change-Id: Ice43057814ee5abd85b2935ffaa91765845a515a
In 1c7f94045a that introduced
DelaySocket, its getPollEvents() could indeed return -1, but that was
removed later.
Change-Id: Ie3a7e01b7b9a7517d97f6ed3cc6d96bdb3313969
Reviewed-on: https://gerrit.libreoffice.org/61990
Reviewed-by: Tor Lillqvist <tml@collabora.com>
Tested-by: Tor Lillqvist <tml@collabora.com>
Add plumbing to send messages from the Online code to the JavaScript
code, and vice versa. Similar to what is done for iOS.
Sadly, it crashes. Multi-thread issues. Not surprisingly, it crashes
when I call webkit_web_view_run_javascript() in another thread than
the one where the GTK+ and other Webkit calls were done. I need to
come up with some clever way to do everything from the same thread.
(On iOS, I use dispatch_async(dispatch_get_main_queue(),...) to
schedule a block (i.e., a lambda expression) to be run in the main
thread.)
The wakeup() call in SocketPoll::stop() doesn't always (or ever?)
actually cause the wakeup code to be invoked and callbacks called
right after, and we don't want to risk the leftover callbacks being
invoked when the same SocketPoll object is started again. (This did
actually happen.)
In a normal Online, this is not a problem, as SocketPolls aren't
reused. One document per kit process, a separate kit process for each
document. Not so in a mobile app, there we have just one process that
handles document after document as the user closes one, opens another
(or the same anew), etc.
Previously SocketPoll expected to be
running its own thread for polling.
This is unnecessary when we have a
spare thread (e.g. main) that can
(and should, for efficiency) be used
for polling rather than starting
dedicated thread.
Not starting the SocketPoll's thread
and calling SocketPoll::poll() directly
worked, the warning logs on each activity
notwithstanding.
The warnings aren't just noisy, they are
a performance drain as well, and signal
that something is wrong. The new code
now makes the API cleaner and avoids
unnecessary warning logs, while being
faster.
Change-Id: Ibf9a223c59dae6522a5fc2e5d84a8ef191b577b1
The async-signal-safe functions to get thread-id
and thread-name, which cache the results, are
faster, cleaner, and signal-safe. No reason why
we shouldn't always use them.
Especially since it appears the logic was
inverted in Log::prefix, such that the signal
un-safe calls were made during signal-handling,
and the safe ones were called otherwise!
Instead of passing the signal-safe flag to
Log::prefix, we pass the buffer size, for
improved security.
Furthermore, reduce header dependencies
and reduce clutter.
Change-Id: I697689b2f0a290b6d8cce4babc3ac1e576141da6
I am trying to get a SocketPoll object to be "restartable".
Also make the lambda expression in joinThread multiple lines, so that
one can set a breakpoint in it.
Makes things simpler and easier to follow, I hope. I had hoped it
would also make the occasional hang I see when loading the document go
away, but nope. Possibly it isn't caused by FakeSocket after all, even
if FakeSocket is the obvious first suspect.
Re-think the plumbing between the different parts of the C++ Online
code. Do try to have it work more like in real Online on all but the
lowest socket level. Except that we don't have multiple processes, but
threads inside the same process. And instead of using actual system
sockets for WebSocket traffic between the threads, we use our own
FakeSocket things, with no WebSocket framing of messages.
Reduce the amount of #ifdef MOBILEAPP a bit also by compiling in the
UnitFoo things. Hardcode that so that no unit testing is ever
attempted, though. We don't try to dlopen any library.
Corresponding changes in the app Objective-C code. Plus fixes and
functionality improvements.
Now it gets so far that the JavaScript code thinks it has the document
tiles presented, and doesn't crash. But it hangs occasionally. And all
tiles show up blank.
Anyway, progress.
Change-Id: I769497c9a46ddb74984bc7af36d132b7b43895d4
No need for explicit "0x" and std::hex when outputting a pointer. A
pointer will be output as a hex number anyway. We used to have things
like this in the log:
TRC #25 Connected to WS Handler 0x0x3610b60| ./net/WebSocketHandler.hpp:80
At least LOOLWSD.cpp has a couple of global variables of types that in
their constructors invoke FakeSocket APIs. If we turn on FakeSocket
logging (fakeSocketSetLoggingCallback()) only in the app's
initialization code, we will miss logging from those global variable
constructors.
Sure, the clean solution would be to turn those global variables into
members in the LOOLWSD class instead, but this will do for now.
Not sure whether the shutdown() implementation matches real shutdown()
semantics, especially with regards to the behaviour of poll(), read(),
and write() (on both the socket itself and the connectd one)
afterwards. But let's see.
The feed() API turned out to be not needed. (And in any case, it was
suposed to be completely equivalent to writing to the peer socket.)
Won't actually be needed anyway, the way the code is going in my work
tree.
Change-Id: I4480ed59fe96ddcfad8483517f2a23452606f332
Reviewed-on: https://gerrit.libreoffice.org/60576
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Miklos Vajna <vmiklos@collabora.co.uk>
It's easier to either call the function to set the logging callback,
or not, in one place in client code, than to comment in and out all
the logging lines in FakeSocket.cpp as needed.
Change-Id: Id17f7e461c7df817440b47cb3124fcece13b189b
As we use #ifdefs at all call sites anyway (because we don't dare use
the generic overrides of close() etc), we can leave out the parameters
related to actual BSD sockets that we ignore anyway.
"Real" Online always uses non-blocking sockets. We don't need to take
flags for that or check it. We can hardcode such behaviour always.
(Assuing that is what we want; let's see once something works.)
Change-Id: I6863907d71c5599b00ce1f8305a44d41bbaf7bee
That is how Online uses the sockets for communication between the
processes anyway: It send and receives complete WebSocket frames.
Sure, in the mobile case there is just one process, but (I think) we
want to keep the same basic structure anyway, even if "wsd" and "kit"
are just threads. (We probably also want to drop the WebSocket framing
of the messages.)
Change-Id: I2397f321029c1cbbbc448a9b2403ad185a51cf14
Intended as a replacement for the real sockets used for WebSocket IPC
in Online on Linux. The idea is that in a mobile app we don't want to
bother with any actual sockets or WebSocket protocol (because we are
running as a single process after all), but keep much of the code that
thinks it is using such mostly unmodified. Just an idea so far, let's
see how this turns out.
Change-Id: I7878b0db99d9cbf70650227186c1fec9677fa74b
Makes it easier to put a breakpoint in it in Xcode...
Not sure if we have any consistent convention around here anyway about
which member functions should be defined inline in the class
definition in the hpp file, and which ones should be in the cpp file.
The app is unimaginatively called "Mobile" for now.
Runs but crashes pretty quickly after loading the document by the LO
core. Will need some heavy changes to get a ClientSession object
created in there, too, to handle the (emulated) WebSocket messages
from the JavaScript. It would then handle some of these messages
itself, and forwards some to the ChildSession, which in this case is
in the same process. Now the messsages from the JavaScript go to a
ChildSession, which is wrong. As the assertion says, "Tile traffic
should go through the DocumentBroker-LoKit WS"
Can't say I understand why, but this turned out to not be a good idea
after all. And no, using constexpr did not work either, so I won't
waste any more time on this triviality, but just revert.
This reverts commit 195b88ac8d.
Change-Id: I49f737dc6a36fa4808841cb8e0335246ad8c6d03
Re-think Linux vs mobile ifdefs a bit. Use #ifdef __linux only to
surround code that actually is Linux-specific. Use #ifdef MOBILEAPP
for code that is for a mobile version (with no separste wsd, forkit,
and kit processes, and with no WebSocket protocol used).
Bypass UnitFoo for mobile. Possibly we do want the UnitFoo stuff after
all on mobile, to run in some special testing mode? Hard to say, let's
skipt it for now.
Again, note that I don't claim this file (or the code-base as such)
would make much sense for iOS as such at the moment. I just want it to
compile for now. Baby steps etc. (And there is no public Xcode project
to compile it even partially.)
Change-Id: I1321d61e9e911c7d97c7309b78aab46d9cecec29
It confused at least me for a while into pondering whether the code
thinks TCP is packet-oriented.
Change-Id: I143fc7821abd6b4023d551cdcb42a00e1613e466
I think the general policy should be to always log errno using both
Util::symbolicErrno() and std::strerror(), never log a naked errno.
But only in cases where we know that it is highly likely that it is
the most recent system call that has failed, so errno makes sense.
Change-Id: I4a1fb31e375ea949e7da17687464361efe7c1761
We had:
auto ipv4 = (struct sockaddr_in *)&clientInfo.sin_addr
even if the clientInfo variable itself was a struct sockaddr_in.
And then we also had:
auto ipv6 = (struct sockaddr_in6 *)&clientInfo.sin_addr
which makes even less sense.
Instead, make clientInfo into a struct sockaddr_in6, which is big
enough to also to be interpreted as a sockaddr_in. Pass the address of
the correct field, either sin_addr or sin6_addr, to inet_ntop(). (Note
that sin_addr in sockaddr_in has a different offset than sin6_addr in
sockaddr_in6.)
At least on my Fedora 28, when I connect using IPv4, accept4() still
returns the client address as an IPv4 mapped IPv6 address, that is
::ffff:192.168.1.113 for 192.168.1.113. So the sample
net.post_allow.host value in loolwsd.xml.in should probably be changed
to have that ::ffff: prefix, too.
Change-Id: I0ad774616b210d94b904982e2f7dc928adc879ed
It was inconsistent that the StreamSocket ctor had a const parameter,
but the SslStreamSocket had a non-const one and used std::move(). Use
the later in the parent class as well for consistency.
Change-Id: I58597b97432a801d164d6ed9d831a0372280e687
moreover:
* noCache is always true in debug mode
* when noCache is true we return an explicit "Cache-Control: no-cache" line
Change-Id: I157a410df0a90f9ab151b899e44566b95cbd9929
Reviewed-on: https://gerrit.libreoffice.org/54517
Reviewed-by: Michael Meeks <michael.meeks@collabora.com>
Tested-by: Michael Meeks <michael.meeks@collabora.com>
This resolves the erroneous warnings of pinging
on a non-upgraded (i.e. HTTP) socket.
This was due to the fact that we moved the socket
from one SocketHandlerInterface to a WebSocketHandler
after upgrading and since the WSState was a property
of the handler, the WebSocketHandler didn't know
that the socket had already been upgraded.
Also other cosmetics and cleanups.
Change-Id: I1a88edef750117ed551d23245e49380371561422
Reviewed-on: https://gerrit.libreoffice.org/49911
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
And improve the logging support in unit-tests to
help troubleshoot issues faster and more accurately.
Also makes the code more readable (hopefully).
Change-Id: I4f8aafb5245e2f774b03231591a74544f9ec84aa
Reviewed-on: https://gerrit.libreoffice.org/48645
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
Using null ssl context to set options is surely not a good idea:
unsigned long SSL_CTX_set_options(SSL_CTX *ctx, unsigned long op)
{
return ctx->options |= op;
}
Change-Id: I2700350e0c3928e372488c81b8111c9ab0b48e06
No derived classes override it, and if they would, that would be a
problem, as setNoDelay() is called from init(), which is called from the
Socket ctor. Calling virtual functions from the base class ctor is not a
good idea, since the object is not fully constructed yet.
Change-Id: I4993e26d09f5d3429c7e2afae7688b84c0061c9d
Two problem types:
- non-final class has virtual functions but no virtual dtor -> mark the
class final
- abstract class has no virtual dtor -> add a virtual dtor
Change-Id: Iae208b65c774e6da7a3dda5e725fe07d4d589e4f
With help from Valgrind to find and verify
these leaks.
Change-Id: I3afeed89dc4bcd714a222f81822144477a346fb0
Reviewed-on: https://gerrit.libreoffice.org/39464
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
