This uses a separate-socket approach since there are systems that do not
support dual binding sockets under *any* circumstances, for instance
OpenBSD. Using separate sockets for IPv4 and IPv6 is thus more portable
than having a v6 socket handle v4 connections as well.
Signed-off-by: Christian Beier <dontmind@freeshell.org>
Support connections from the Mac OS X built-in VNC client to
LibVNCServers running with no password and advertising a server
version of 3.7 or greater.
Lengthy explanation follows...
First, the scenario before this patch:
We have three clients 1,2,3 connected. The main thread loops through
them using rfbClientIteratorNext() (loop L1) and is currently at
client 2 i.e. client 2's cl_2->refCount is 1. At this point we need to
loop again through the clients, with cl_2->refCount == 1, i.e. do a
loop L2 nested within loop L1.
BUT: Now client 2 disconnects, it's clientInput thread terminates its
clientOutput thread and calls rfbClientConnectionGone(). This LOCKs
clientListMutex and WAITs for cl_2->refCount to become 0. This means
this thread waits for the main thread to release cl_2. Waiting, with
clientListMutex LOCKed!
Meanwhile, the main thread is about to begin the inner
rfbClientIteratorNext() loop L2. The first call to rfbClientIteratorNext()
LOCKs clientListMutex. BAAM. This mutex is locked by cl2's clientInput
thread and is only released when cl_2->refCount becomes 0. The main thread
would decrement cl_2->refCount when it would continue with loop L1. But
it's waiting for cl2's clientInput thread to release clientListMutex. Which
never happens since this one's waiting for the main thread to decrement
cl_2->refCount. DEADLOCK.
Now, situation with this patch:
Same as above, but when client 2 disconnects it's clientInput thread
rfbClientConnectionGone(). This again LOCKs clientListMutex, removes cl_2
from the linked list and UNLOCKS clientListMutex. The WAIT for
cl_2->refCount to become 0 is _after_ that. Waiting, with
clientListMutex UNLOCKed!
Therefore, the main thread can continue, do the inner loop L2 (now only
looping through 1,3 - 2 was removed from the linked list) and continue with
loop L1, finally decrementing cl_2->refCount, allowing cl2's clientInput
thread to continue and terminate. The resources held by cl2 are not free()'d
by rfbClientConnectionGone until cl2->refCount becomes 0, i.e. loop L1 has
released cl2.
I was debbuging some code tonight and i found a pointer that is not been
freed, so i think there is maybe a memory leak, so it is...
there is the malloc caller reverse order:
( malloc cl->statEncList )
<- rfbStatLookupEncoding
<- rfbStatRecordEncodingSent
<- rfbSendCursorPos
<- rfbSendFramebufferUpdate
<- rfbProcessEvents
I didnt look the whole libvncserver api, but i am using
rfbReverseConnection with rfbProcessEvents, and then when the client
connection dies, i am calling a rfbShutdownServer and rfbScreenCleanup,
but the malloc at rfbStatLookupEncoding isnt been freed.
So to free the stats i added a rfbResetStats(cl) after rfbPrintStats(cl)
at rfbClientConnectionGone in rfbserver.c before free the cl pointer. (at
rfbserver.c line 555). And this, obviously, is correcting the memory leak.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Move the hixie disconnect hack to websockets.c. Removed
the remaining websockets vars from rfbClientPtr, so all
websockets stuff is hidden behind an opaque pointer.
[jes: moved out GnuTLS and OpenSSL support, added a dummy support, to
separate changes better, and to keep things compiling]
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
This is not completely standard UTF-8 encoding. Only code points 0-255
are encoded and never encoded to more than two octets. Since '\x00' is
a WebSockets framing character, it's easier for all parties to encode
zero as '\xc4\x80', i.e. 194+128, i.e. UTF-8 256.
This means that a random stream will be slightly more than 50% larger
using this encoding scheme. But it's easy CPU-wise for client and
server to decode/encode. This is especially important for clients
written in languages that have weak bitops, like Javascript (i.e. the
noVNC client).
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
If the only thing we are waiting on is a WebSockets terminator, then
remove it from the stream early on in rfbProcessClientNormalMessage.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Has a bug: WebSocket client disconnects are not detected.
rfbSendFramebufferUpdate is doing a MSG_PEEK recv to determine if
enough data is available which prevents a disconnect from being
detected.
Otherwise it's working pretty well.
[jes: moved added struct members to the end for binary compatibility with
previous LibVNCServer versions, removed an unused variable]
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
This adds generic before/after encoding buffers to the rfbClient
struct, so there is no need for thread local storage.
Signed-off-by: Christian Beier <dontmind@freeshell.org>
This implements the xvp VNC extension, which is described in the
community version of the RFB protocol:
http://tigervnc.sourceforge.net/cgi-bin/rfbproto
It is also mentioned in the official RFB protocol.
Expands the SetNonBlocking() function in libvncclient/sockets.c to also
work under Windows and also changes it to honour maybe already present
socket flags.
A similar function was introduced for libvncserver as well and
all the #ifdef'ed fnctl calls replaced with calls to that one.
Signed-off-by: Christian Beier <dontmind@freeshell.org>
To make this work, we also have to initialize sockets
to a default value of -1.
Also close a client listen socket if it's open.
Signed-off-by: Christian Beier <dontmind@freeshell.org>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
There was a long standing TODO to make the counting of the supported
encodings dynamic. It never triggered, until ZYWRLE was added.
Noticed by Christian Ehrlicher.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
When swapping the values for the colour table to little-endian (because
they are 16-bit values), we need to cast "unsigned char" to "unsigned
short"; otherwise, Microsoft's compiler would keep complaining.
Noticed by Christian Ehrlicher.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
The variable tightQualityLevel is used for ZYWRLE compression, too,
so if libjpeg is not present, but libz is, we still need to have
that struct member.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
We used to assume that a char[256] is properly aligned to be cast to
an rfbServerInitMsg, but that was not the case. So use a union instead.
Noticed by Flavio Leitner.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
There seems to be a locking problem in libvncserver, with respect to how
condition variables are used.
On certain machines in our lab, when using a vncviewer to view a display
that has a very high rate of updates, we will occasionally see the VNC
server process crash. In one stack trace that was obtained, an assertion
had tripped in glibc's pthread_cond_wait, which was called from
clientOutput.
Inspection of clientOutput suggests that WAIT is being called incorrectly.
The mutex that protects a condition variable should always be locked when
calling wait, and on return from the wait will still be locked. The
attached patch fixes the locking around this condition variable, and one
other that I found by grepping the source for similar occurrences.
Signed-off-by: Charles Coffing <ccoffing@novell.com>
rfbEncodingSupportedEncodings - What encodings are supported?
rfbEncodingSupportedMessages - What message types are supported?
rfbEncodingServerIdentity - What is the servers version string?
ie: "x11vnc: 0.8.1 lastmod: 2006-04-25 (LibVNCServer 0.9pre)"
Christian Beier
Kyle J. McKay
George Fleury
Gernot Tenchio
Joel Martin
George Kiagiadakis
runge
Tobias Doerffel
runge
dscho
steven_carr