Avoid duplicating all the memory mangement, and instead use the
BufferedOutStream as a base clase for all out streams that need an
intermediate buffer.
Major restructuring of how streams work. Neither input nor output
streams are now blocking. This avoids stalling the rest of the client or
server when a peer is slow or unresponsive.
Note that this puts an extra burden on users of streams to make sure
they are allowed to do their work once the underlying transports are
ready (e.g. monitoring fds).
We use a lot of lengths given to us over the network, so be more
paranoid about them causing an overflow as otherwise an attacker
might trick us in to overwriting other memory.
This primarily affects the client which often gets lengths from the
server, but there are also some scenarios where the server might
theoretically be vulnerable.
Issue found by Pavel Cheremushkin from Kaspersky Lab.
Provides safety against them accidentally becoming negative because
of bugs in the calculations.
Also does the same to CharArray and friends as they were strongly
connection to the stream objects.
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.
In earlier Visual Studio and MinGW editions, BSD socket errno:s were
left undefined. This is no longer the case. This may cause build or
runtime errors. To avoid this, we are using a common header file which
corrects all definitions. This header will also be used with other
projects such as sercd, unfs3, PulseAudio etc.
Make socket writes non-blockable. This allows the system to more quickly
return back to the Xorg main loop, meaning that things will be more responsive
in the presence of slow VNC clients.
git-svn-id: svn://svn.code.sf.net/p/tigervnc/code/trunk@4735 3789f03b-4d11-0410-bbf8-ca57d06f2519
Removed the FdOutStream::writeBytes() implementation as the same
method of the parent class seems to do the work better. The function
can flush buffered data even if there were only a few bytes in the
buffer. That results in sending packets with just 1 byte of data,
while encoding data with 32-bit Hextile.
git-svn-id: svn://svn.code.sf.net/p/tigervnc/code/trunk@318 3789f03b-4d11-0410-bbf8-ca57d06f2519
Pierre Ossman
Peter Åstrand (astrand)
Adam Tkac
Constantin Kaplinsky