Vine Server - multiple view-only clients for the same screen

Vine
#1

Hello forums,

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.

Thanks in advance for your input!

#2

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.

#3

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!

#4

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.

#5

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 -alwaysshared -rfbauth vncpasswd -dontdisconnect -disableremoteevents -localhost -maxauthattempts 10000 -useopengl -rfbport 25901

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.

Thanks again for your great input!

#6

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 :wink:

#7

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.

#8

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?

Thanks a bunch in advance! :slight_smile:

#9

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).

#10

Neat, spammers using Markov chains… and I was so happy that finally, someone would be responding to my latest post ;(

#11

I’m bumping this once more… can anyone tell me how to trace (bot hon the syscall and library level) a running Intel-binary on OS X?

Or is there any other way of getting to know what Vine is doing right before shutting down?

Please let me know if you’ve got an idea!

Thanks in advance, have a nice day!

#12

OK, I’ve got the time to set up a testing environment on 10.6 today, and I’ve come up with some new data.

Vine Server shoots itself with a “Bus Error”:


2009-11-17 14:51:20.111 vncd[909:4207] Pixel format for client 127.0.0.1:
2009-11-17 14:51:20.112 vncd[909:4207]   32 bpp, depth 24, little endian
2009-11-17 14:51:20.112 vncd[909:4207]   true colour: max r 255 g 255 b 255, shift r 16 g 8 b 0
2009-11-17 14:51:20.113 vncd[909:4207] Client Connected - Registering Screen Update Notification
vncd(909,0xb032b000) malloc: *** error for object 0x70659f: pointer being reallocated was not allocated
*** set a breakpoint in malloc_error_break to debug
2009-11-17 14:51:22.787 vncd[909:4207] Client 127.0.0.1 disconnected
2009-11-17 14:51:22.789 vncd[909:4207] Statistics:
2009-11-17 14:51:22.790 vncd[909:4207]   framebuffer updates 6, rectangles 127, bytes 113554
2009-11-17 14:51:22.791 vncd[909:4207]     LastRect markers 5, bytes 60
2009-11-17 14:51:22.791 vncd[909:4207]     Tight rectangles 120, bytes 111094
2009-11-17 14:51:22.792 vncd[909:4207]     Cursor Shape Updates rectangles 1, bytes 2388
2009-11-17 14:51:22.793 vncd[909:4207]     Cursor Position Updates rectangles 1, bytes 12
2009-11-17 14:51:22.793 vncd[909:4207]   raw bytes equivalent 6569496, compression ratio 57.884082
2009-11-17 14:51:22.797 vncd[909:903] UnRegistering Screen Update Notification - waiting for clients
2009-11-17 14:51:27.020 vncd[909:420b] rfbProcessClientProtocolVersion: client gone
2009-11-17 14:51:27.021 vncd[909:420b] Client 127.0.0.1 disconnected
2009-11-17 14:51:27.022 vncd[909:420b] Statistics:
2009-11-17 14:51:27.023 vncd[909:420b]   framebuffer updates 0, rectangles 0, bytes 0
vncd(909,0xb0103000) malloc: *** error for object 0xc1c1c1c1: pointer being freed was not allocated
*** set a breakpoint in malloc_error_break to debug
2009-11-17 14:51:27.040 vncd[909:903] Waiting for clients
2009-11-17 14:51:29.742 vncd[909:400b] Protocol version 3.3
2009-11-17 14:51:29.743 vncd[909:400b] Ignoring minor version mismatch
2009-11-17 14:51:30.012 vncd[909:400b] ENCODING: Tight for client 127.0.0.1
2009-11-17 14:51:30.013 vncd[909:400b]  Enabling LastRect protocol extension for client 127.0.0.1
2009-11-17 14:51:30.014 vncd[909:400b]  Using compression level 9 for client 127.0.0.1
2009-11-17 14:51:30.015 vncd[909:400b]  Using jpeg image quality level 5 for client 127.0.0.1
2009-11-17 14:51:30.016 vncd[909:400b]  Enabling Cursor Shape protocol extension for client 127.0.0.1
2009-11-17 14:51:30.016 vncd[909:400b]  Enabling Cursor Position protocol extension for client 127.0.0.1
Bus error

Command line used:

./vncd -rfbport 25901 -alwaysshared -rfbauth vncpasswd -dontdisconnect -disableRemoteEvents -localhost -maxauthattempts 0 -useOpenGL

That looks like some memory housekeeping is going awry, doesn’t it?

I’ll keep experimenting with Vine’s invocation, maybe there’s some command line argument that triggers that specific problem/bug.

I don’t really know how to debug applications on OS X, but there’s a chance I’ll have a look into DTrace somewhat later this week.

#13

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?

#14

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.

Regardless, keep up the good work with Vine! :slight_smile: