| Commit message (Collapse) | Author | Age | Files | Lines |
|\ |
|
| |
| |
| |
| |
| | |
The hextileDecodexx functions do not properly check for out-of-bounds writes,
which allows a malicious server to overwrite parts of the stack.
|
|/ |
|
|
|
|
|
|
|
| |
This bug was introduced in c6df31db. A non-blocking socket that did
not have any more space would busy loop until the write succeeded.
Instead now it returns without any action, just as it did before
the bug was introduced.
|
|
|
|
|
| |
Any caller using add or remove should also be able to list the
sockets.
|
|
|
|
|
| |
Some of these were excessively large because of redundant factors
in the size calculation.
|
| |
|
| |
|
|
|
|
|
|
| |
These are reference counted so it is important to retain symmetry
between the calls. Failure to do so will result in bad memory access
and crashes.
|
|
|
|
|
| |
168b92c broke the handling that assumes display 100 and above are
actually a port number.
|
|
|
|
| |
Use the platform independent primitives instead.
|
| |
|
| |
|
|
|
|
|
| |
It now does more validation, and handles unescaped IPv6 addresses
better.
|
|
|
|
|
|
|
| |
We might be linking our Xregion and libX11 into the same binary,
causing a clash between the symbols. In theory they should be
compatible, but that's not guaranteed. Avoid the issue by adding
a "vnc" prefix to our version.
|
| |
|
|
|
|
|
| |
We've stolen the Xregion code from libX11, so let's keep the same
header naming so that it is easier to keep things in sync.
|
| |
|
|
|
|
|
|
| |
There might be stuff lingering in the buffer simply because flush()
hasn't been called in a while, rather than because the transport is
congested.
|
|
|
|
|
|
| |
We now get notifications when the output buffer empties, and we
already caught incoming RTT pongs, meaning we can now react at the
proper time to retry a congested update rather than use a timer.
|
|
|
|
|
| |
This makes sure we keep the socket busy even if one rect takes some
time to encode.
|
|
|
|
|
|
| |
What to do when a socket is writeable should be handled in the
RFB core code as there may be other events we want to fire off
when this happens.
|
|
|
|
| |
The logic was a bit confusing and superfluous.
|
|
|
|
| |
We haven't supported such an old version of Windows for some time.
|
| |
|
| |
|
|
|
|
|
| |
There are more platforms than x86_64 that need -fPIC, so include
it whenever possible.
|
|
|
|
|
|
| |
The previous detection would fail if the socket closed before we
had time to inspect it, which got us stuck in a loop as we would
try (and fail) to do accept() on a non-listening socket.
|
| |
|
|
|
|
|
| |
Only C++11 allows omitting the class keyword, so include it so
the code compiles with older compilers.
|
|
|
|
|
|
| |
Parsing a filter might be the first thing we do so we need to
make sure the socket subsystem is running so that we can look
up names.
|
| |
|
|
|
|
|
| |
They just end up burning CPU fighting each other without much
improvement to the decoding time beyond four threads.
|
| |
|
|
|
|
|
|
| |
We can start creating more decoding threads now that we handle
rect ordering properly. No point in creating more threads than
there are CPUs though.
|
|
|
|
|
|
| |
The cost is some more load on malloc(), but it should be small
compared to the gains of spreading the CPU heavy JPEG decoding
over multiple CPUs.
|
|
|
|
|
|
| |
Some encodings only cause dependencies between rects some of the
time. Make sure we can allow parallel decoding of those rect that
aren't dependent on each other.
|
|
|
|
|
| |
Some encodings must be handled in the order they are received.
Make sure we respect this in the decode manager.
|
| |
|
|
|
|
|
| |
Allows us to add attributes later that affect of the decoder
manager deals with the decoders.
|
|
|
|
|
|
|
| |
This implements the basic infrastructure for multi-threaded
decoding of rects. However there is just one thread reading data
and one thread decoding it. More logic is needed to safely decode
multiple rects at the same time.
|
|
|
|
|
| |
We need more callbacks for correct operation of multi-threaded
rect decoding.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
It previously only did a reset of the ZlibInStream object, not the
underlying zlib stream. It also had the side effect of flushing
the underlying stream and disassociating from it.
Clear things up by changing the naming, and introducing a proper
reset function (which is needed by the Tight decoder).
|
|
|
|
|
|
|
|
| |
We need to split these steps up in preparation for multi-core
support. Reading needs to be done in a serial manner, whilst
decoding can be done in parallel.
This also involved a rather large cleanup of the Tight decoder.
|
| |
|
| |
|
| |
|
| |
|