I’d like to set up Vine Server on OS X 10.6.x in a way that multiple view-only clients may connect to it at the same time, and each of those clients is presented with the very same image (module individual network latency, of course).Is that possible with Vine Server, and if yes, how? Are there any prerequisites the client(s) must fulfill?
I’ve fiddled around with “shared mode” (-alwaysshared) a bit, but that doesn’t seem to do the trick.
Please note that I’m working with (read:invoking) Vine from the command line, so it’d be most helpful if someone could provide me with a recipe to start Vine the way I need it to in a way that does not involve the GUI.
Typically for VNC connections (and true of Vine Server) you can have the server in one of three modes:[list]Always allow multiple connections
Never allow multiple connections
Let the client request[/list:u]
You’ve found the proper setting to put the server in “Always share the screen mode” so from the server side everything seems to be in order. The only other problem you might have is if your VIEWERS that are set to ONLY allow connections if they get private access, so check your viewer side. But normally what you’ve done should work.
I see, many thanks for definitely confirming what I’ve been assuming! The viewer in questions is FlashLight VNC (a Adobe Flash/Flex application), and it has a feature called “shared mode”, which I had enabled.
However, we’re using OpenSSH with remote port forwarding to avoid packet filtering problems (most of the machines we’re interested in broadcasting screens from via VNC are behind masquerading routers) on an Internet-exposed server to relay incoming VNC client connections to the serving machines - could that be why it doesn’t work as intended?
Again, thanks for your quick and clear reply; it’s highly appreciated!
Open SSH shouldn’t be causing any problems. The SSH daemon on Mac OS X definitely supports multiple simultaneous connections.
You might try it with Vine Viewer or RealVNC as a client (We’ve used both of those enough to know for sure they work) – if they DO you know it’s a problem with the client.
OK, I’ve invested a bit of time today, and it seems that the problem somehow relates to Vine Server. I set up another VNC host machine running GNU/Linux, X11 and x11vnc - multiple clients (multiple instances of the flash client we intend to use) work just fine; I stopped testing at four concurrent client connections. The individual VNC host computer setups don’t differ from platform to platform; there’s always an SSH tunnel between the VNC host and the VNC clients.
There also seems a problem with how Vine handles subsequent failing and/or succeeding connection attempts; after a few (unfortunately, I could not nail down a definite number - but it’s less than 10) connection attempts to its listening socket, the daemon just silently exits.
The command line we use to invoke Vine server reads as follows:
vncd is a symlink pointing to OSXvnc-server in the application bundle, Vine Server is Version 3.1 from this site, and the host OS is Mac OS 10.6.1. “vncpasswd” is a file in the currect working directory containing a valid (encrypted) VNC password string.
How can I keep Vine server from exiting even if some client makes connection attempts that do or do not succeed? (Fwiw, I think that -maxauthattempts should take care of that, but apparently, it doesn’t. Might this be a bug in Vine Server?) How can I make Vine tell me why it’s shutting down? It doesn’t report anything to stdout or stderr upon exiting, afaict. I basically would like to have Vine running no matter what, untell I send SIGTERM to make it shut down.
I’m sorry to bump this soon, but it’d be awesome to get a comment on my musings - that’s the only thing unchecked yet for this little project of mine to be completed, and I’d like to move on to other tasks, without that issue still clogging my mind in the background
You might try disabling some encodings – there might be a thread bug in one of the them. Can you describe further what goes “wrong” when you add additional clients.
The problem is that the Vine Server process literally disappears from the process table of the host’s operating system. It also doesn’t bind any sockets any more at that point, so I guest it exits nicely. There’s no output whatsoever on stdout/stderr, it’s just gone. I noticed that in the past, when I tested various OS X hosts for availability of the Vine Server via telnet or netcat (I tore down the socket connection once the RFB header appeared to have it made thru) - after some unsuccessful attempts, Vine just stops running, and I cannot connect any more.
The only encoding we’re interested in using (and actually are using, afaict) is “Tight”. How would I go about disabling all the others Vine provides?
I dug into one of the system’s again today, and there is some output on stderr this time:
macmini:Vine Server.app ep$ ./OSXvnc-server -alwaysshared -rfbauth vncpasswd -dontdisconnect -disableRemoteEvents -maxauthattempts 0 -useOpenGL
2009-11-04 14:21:30.917 OSXvnc-server[1238:10b] Arguments: -alwaysshared -rfbauth vncpasswd -dontdisconnect -disableRemoteEvents -maxauthattempts 0 -useOpenGL
2009-11-04 14:21:30.918 OSXvnc-server[1238:10b] Using OpenGL display
2009-11-04 14:21:30.919 OSXvnc-server[1238:10b] Main Bundle: /Users/ep/showcase/res/Vine Server.app
2009-11-04 14:21:30.921 OSXvnc-server[1238:10b] Loading Bundle /Users/ep/showcase/res/Vine Server.app/Contents/Resources/TigerBundle.bundle
2009-11-04 14:21:30.923 OSXvnc-server[1238:10b] Loading Bundle /Users/ep/showcase/res/Vine Server.app/Contents/Resources/JaguarBundle.bundle
2009-11-04 14:21:30.930 OSXvnc-server[1238:10b] Running in Little Endian
2009-11-04 14:21:30.931 OSXvnc-server[1238:10b] Pasteboard Inaccessible - Pasteboard sharing disabled
2009-11-04 14:21:30.932 OSXvnc-server[1238:10b] Waiting for clients
2009-11-04 14:21:30.933 OSXvnc-server[1238:1e03] Using Private Event Source
2009-11-04 14:21:30.935 OSXvnc-server[1238:1e03] Unable to get session dictionary.
2009-11-04 14:21:30.935 OSXvnc-server[1238:1e03] Using Smart Event Tap -- Session for off-screen user
2009-11-04 14:21:30.937 OSXvnc-server[1238:1e03] Registering Bonjour Service(_rfb._tcp.) - macmini.lan
2009-11-04 14:21:30.938 OSXvnc-server[1238:3303] IPv6: Started Listener Thread on port 5900
2009-11-04 14:21:30.938 OSXvnc-server[1238:1e03] Started Listener Thread on port 5900
2009-11-04 14:21:34.961 OSXvnc-server[1238:3c03] rfbProcessClientProtocolVersion: client gone
2009-11-04 14:21:34.984 OSXvnc-server[1238:10b] Waiting for clients
2009-11-04 14:21:37.169 OSXvnc-server[1238:5607] rfbProcessClientProtocolVersion: client gone
2009-11-04 14:21:37.201 OSXvnc-server[1238:10b] Waiting for clients
2009-11-04 14:21:39.264 OSXvnc-server[1238:10b] OSXvnc-server received signal: 15
2009-11-04 14:21:39.265 OSXvnc-server[1238:10b] Unloading Tiger Extensions
2009-11-04 14:21:39.266 OSXvnc-server[1238:10b] Unloading Jaguar Extensions
2009-11-04 14:21:39.267 OSXvnc-server[1238:10b] Disabling Bonjour Service - macmini.lan
2009-11-04 14:21:39.268 OSXvnc-server[1238:10b] Removing Observers
2009-11-04 14:21:39.269 OSXvnc-server[1238:10b] RFB Shudown Complete
This does happen when I connect to Vine via telnet, and tear down the connection (by quitting telnet) afterwards for three times in a row - though it is not ALWAYS the case! I hav one instance of Vine “survive” many, many connection attempts in the very same manner as described once today.
Note that I do not send SIGTERM myself; I don’t know where it’s coming from.
Any ideas on how to debug this further? Is anyone of you able to reproduce this behaviour (I observed it on three different installations of OS X by now).
OK, this time Vine barfed with a good old segfault, so there’s definitely something wrong with memory management. The problems seems to be connected with how Vine handles connection requests on the socket it listens on: I use a simple script that opens Vine’s listening socket and read the RFB Header/Version information to “probe” if there’s a VNC server running, and just close the socket afterwards. Vine does not seem to like this, and occasionally goes down in fire.
Is there someone of you willing to look into the problem?
Just quickly dropping by to let you know that we switched to x11vnc for the project - it supports the Mac OS X display server (we didn’t know that until two days ago), and it runs excetionally well.
