I am running the vine server on my mc mini. When I try to connect it from one vnc client (Windows ), it works great. But it does not work for multiple vnc clients.
I am using java vnc clients on my Window machines.
I also tried with the settings “Always allow multiple vnc connections”.
Any suggestion?
In order to help us diagnose this problem, could you please further describe what happens when you attempt the second connection.
Is it rejected with an error?
Does the first one become disconnected?
Does the server crash?
If you disconnect the first one and do the same thing in the other order is the behavior the same?
[quote=“JonathanOSX”]In order to help us diagnose this problem, could you please further describe what happens when you attempt the second connection.
Is it rejected with an error?
Does the first one become disconnected?
Does the server crash?
If you disconnect the first one and do the same thing in the other order is the behavior the same?[/quote]
When one client connects to the Vine Server, the picture on the client side side is OK. However, when more than one client connects, the images on the viewing clients become garbled.
I noticed this behavior for OSXvnc v 1.7 - 2.0, inclusive.
We aren’t seeing that behavior here with all clients. Can you precisely identify which two clients you are using which cause that behavior. Also, which version of Mac OS is the Server running on?
We tried to run the server first on OSX 10.4.7 Intel core duo then on 10.4.8 Power PC G4.
We ran the tightvnc java viewer on 3 Windows machines.
We also tried with Tightvnc Windows native viewer.
We did not see any issue when we ran the same clients with a Tight vnc server running on a Windows machine
Which build of TightVNC was it?
I am using tigngvnc 1.3.8 java viewer and 1.3.8 tighvnc server
I had the same problem at work. A co-worker was sharing stuff from iPhoto, and me and two other guys who had TightVNC on Windows machines were trying to see his desktop at the same time, and the images were all messed up, and the rendering took forever.
We could only get it to work with one computer looking at the Mac screen. Am thinking VineServer is only meant for one PC to view. Correct?
Vine Server is definitely set to support multiple simultaneous connections to the same desktop. I just ran a test where 4 machines were connected and watching at once.
[list]Two Mac OS 10.4 machines running Vine Viewer
One WindowsXP machine running TightVNC 1.2.9 (native, not java)
One WindowsXP machine running RealVNC 4.1.2[/list:u]
I would like to track down whatever incompatibility we are looking at so let me ask some questions to the people experiencing this problem.
What Hardware(PPC/Intel?) and Vine Server Version is the server running?
Under Vine Server->Sharing how is Server Sharing set?
Have you checked that the VNC clients are “allowing a shared connection” as opposed to exclusive access. This is usually a connection option within the client?
For the VNC Client(s) what OS, client, and client version you are running?
I heard some discussion of running the TightVNC JAVA client. Since most people only run the JAVA client when connecting on port 5800 (which Vine Server doesn’t internally support) can you describe that configuration in greater detail?
[quote=“JonathanOSX”]Vine Server is definitely set to support multiple simultaneous connections to the same desktop. I just ran a test where 4 machines were connected and watching at once.
[list]Two Mac OS 10.4 machines running Vine Viewer
One WindowsXP machine running TightVNC 1.2.9 (native, not java)
One WindowsXP machine running RealVNC 4.1.2[/list:u]
I would like to track down whatever incompatibility we are looking at so let me ask some questions to the people experiencing this problem.
What Hardware(PPC/Intel?) and Vine Server Version is the server running?
Under Vine Server->Sharing how is Server Sharing set?
Have you checked that the VNC clients are “allowing a shared connection” as opposed to exclusive access. This is usually a connection option within the client?
For the VNC Client(s) what OS, client, and client version you are running?
I heard some discussion of running the TightVNC JAVA client. Since most people only run the JAVA client when connecting on port 5800 (which Vine Server doesn’t internally support) can you describe that configuration in greater detail?[/quote]
Here is the hardware/software config that I use to reproduce the problem. . .
One Vine Server (latest version) running on a Mac OS X 10.4.7 (Tiger) box.
Two Tight VNC Java clients (v 1.2.9, binary class file distribution, downloaded from http://www.tightvnc.com), each running on a Windows 2000 SP4 box connecting to the Mac OS X box.
When the first viewer connects, the images are fine. When the SECOND viewer connects, the images on one or both are garbled and/or one of the viewers crashes with a “Corrupt JPEG data” or “End of SOF” error message. Same results with more than 2 TightVNC Java viewers and/or Java viewers running on XP or Mac OS X.
This same behavior is NOT noticed when the Java viewers connect to a TightVNC server running on Windows 2000 or XP, i. e. with this server, mutiple TightVNC Java clients connect and display images with no problem, regardless of what platform the Java clients run on.
ALSO, I noticed this problem GOES AWAY when the Java viewers are re-compiled with the “Hextile” encoding (as opposed to the “Tight” encoding which comes with the distribution). With the Hextile encoding mechanism, multiple Java viewers can connect to the Vine Server and view the OS X desktop with no problem.
You can try this yourself as follows. . .download the Java TightVNC viewer source (tightvnc-1.2.9_javasrc.zip from http://www.tightvnc.com/) and in the file OptionsFrame.java, change the line of code
choices[encodingIndex].select(“Tight”);
to
choices[encodingIndex].select(“Hextile”);
Recompile the Java code and within the vnc_javasrc directory, run as
java VncViewer HOST (IP addr. of PC running Vine Server) PORT 5900
on two or more PCs (Mac or Win), and everything works fine. The pre-compiled version of the code (tightvnc-1.2.9_javabin.zip) however, has this option set to “Tight”.
Similar behavior occurs with the executable distribution of TightVNC (vncviewer.exe). On Windows, once this is installed, if you go to Start->Programs->TightVNC->Fast Comression on two or more Windows 2000/XP machines connecting to the Vine Server, the rendering/images are OK.
However, if you go to Start->Programs->TightVNC->Best Compression on two or more Windows 2000/XP machines connecting to the Vine Server, the images on one or more are garbled and/or one or more of the viewers crashes with some imaging error.
It appears, based on this experiment, that OSXvnc has a problem with two or more simultaneous connections when the viewers are using “Tight encoding”.
Babuna:
Thank you very much for your analysis!
Tight encoding does appear to be the trigger condition. It also explains why there is no problem using any number of RealVNC or Vine Viewer clients (plus any single Tight client). It’s also consistent with the behavior of the screen corruption if there is thread vulnerability in Vine Server’s TightVNC code.
We just issued a new server (2.1) but now that we have this narrowed down I can start looking into fixing the multiple Tight encoding connection issue.
[quote=“JonathanOSX”]Babuna:
Thank you very much for your analysis!
Tight encoding does appear to be the trigger condition. It also explains why there is no problem using any number of RealVNC or Vine Viewer clients (plus any single Tight client). It’s also consistent with the behavior of the screen corruption if there is thread vulnerability in Vine Server’s TightVNC code.
We just issued a new server (2.1) but now that we have this narrowed down I can start looking into fixing the multiple Tight encoding connection issue.[/quote]
Great, thanks so much for all your help.
You mentioned thread vulnerability. I looked at the file tight.c in the OSXvnc-server code. It appears there are alot of static variables being used (tightBeforeBufSize, tightBeforeBuf, etc.) for all client threads. In WinVNC’s code, however, the variables used for the Tight encoding are all instance (per-object) variables–see vncEncodeTight.h in the WinVNC sources.
Was wondering if the reason for the thread vulnerability is due to these variables in tight.c being all static (used by all client threads) as opposed to per-client variables.
Just a hunch, that’s all.
You’re almost certainly correct that this is the problem. We didn’t write the original Tight encoding logic inside the server. It was ported over from an older version of TightVNC.
Was wondering how if you guys succeeded in fixing this bug yet, in v 2.1. Let me know. THX.
Unfortunately we identified that bug after 2.1 came out; so it’s not fixed there. We haven’t made any changes in the server but I’ll be sure to post a followup when a fix is checked into SourceForge.
I was able to correct the problem. Basically, removed all static vars in tight.c and placed them in the client struct in rfb.h. Used macro subbing
to update function calls and var references to keep most of the code the same. rfb.h, tight.c, rfbserver.c modified, tight.h added. Tested w/3 clients all using tight encoding. If you’d like the new code, lemme know 
btw, here’s a link to the code changes I made. Can xtract this above the root of the OSXvnc tree and re-compile. . .
Thanks solletica! For what it’s worth those changes have been incorporated and we are very close to releasing the next version of Vine Server (with this fix).