The extended clipboard protocol has the ability for the peer to request
things to be sent automatically, without a request message. Make sure we
honor such settings.
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).
Some systems (like TLS) need to send some final data before closing
a connection. Make sure this is properly handled by cleaning up the
security object before closing the underlying network socket.
Implements support in both client and server for the extended
clipboard format first seen in UltraVNC. Currently only implements
text handling, but that is still an improvement as it extends the
clipboard from ISO 8859-1 to full Unicode.
This provides some basic rate limiting that will make it difficult
for an attacker to brute force passwords. Only relevant when the
blacklist is disabled as otherwise the attacker only gets a very
limited number of attempts.
Make arguments explicit in all message writer methods
Make sure all methods only write what is given as arguments, and
avoid side effects by getting data from parameter objects. This keeps
things readable in the calling code.
This adds the basic infrastructure and handshake for the QEMU
Extended Key Events extension. No viewer or server makes use of
the extra functionality yet though.
They are created in SConnection's and CConnection's constructors but never destroyed.
There is no reason for the indirection, so lets make them direct members.
A read-only client should not be allowed to kick out other clients.
It will be forced into shared mode, or refused the connection, depending
on the neverShared parameter.
Allow SSecurity to specify AccessRights for SConnection.
SConnection has AccessRights property that specifies what connected client can
do. Set this property to value given by SSecurity after successful
authentication. This way individual SSecurity subclasses can accept clients but
restrict their access.
Move preferred encoding tracking into a server object
Having it in ConnParams made the linker pull all the encoder objects
into vncviewer, making it larger than necessary and giving it extra
parameters in its help output that weren't relevant.
Gets rid of a loooot of code and complexity.
Colour map clients are still supported through an
automatically generated map, but we lose the ability to
develop a client or server that uses colour maps
internally.
Eliminate GCC signed/unsigned warnings related to encodings: The
encoding in the RFB protocol has always been signed, and signed values
are also used in the specification (ie DesktopName = -307 etc). In the
code, however, unsigned types were used in a number of places, but not
all, which causes warnings. This patch fixes the problem by switching
to signed values everywhere.
git-svn-id: svn://svn.code.sf.net/p/tigervnc/code/trunk@3968 3789f03b-4d11-0410-bbf8-ca57d06f2519
Remove the "video" feature and its associated custom JPEG handling.
Having the client specifiy the video region is conceptually wrong
and a problem like this should be handled by better encoding selection.
git-svn-id: svn://svn.code.sf.net/p/tigervnc/code/trunk@3635 3789f03b-4d11-0410-bbf8-ca57d06f2519
Removed support for continuous updates, a TightVNC-specific RFB protocol
extension. That extension used to send framebuffer updates continuously, not
waiting for clients' requests. However, it showed bad results with
low-bandwidth connections, due to lack of proper data flow control.
git-svn-id: svn://svn.code.sf.net/p/tigervnc/code/trunk@2581 3789f03b-4d11-0410-bbf8-ca57d06f2519
Initial implementation of continuous updates in the server code. This code does not handle framebuffer size changes properly yet. Also, the server does not send the client EndOfContinuousUpdates message yet (documented in doc/rfbproto.tex).
Reverted the changes appeared in revisions 2173,2181. We better always send the "security result" message in the protocol version 3.8, even after an empty list of authentication capabilities.
Corrected support for TightVNC extensions - always sending authentication capability list even when authentication is not required. This may be incompatible with certain TightVNC viewers but this is the way to allow "no authentication" AND prompting local user to accept/reject incoming connection.
Pierre Ossman
Michal Srb
Henrik Andersson
Adam Tkac
Peter Åstrand
Constantin Kaplinsky