turboVNC as mini collaboration suite?

Help
sega lion
2012-01-12
2013-11-26
  • sega lion
    sega lion
    2012-01-12

    I was trying turbovnc on windows enviroment to create a mini collaboration suite:

    1. up to 10 simultaneous participants seen my desktop (full/window)
    2. only reading
    3. on LAN/MAN enviroment

    I would like if anybody make similar tests like this to know CPU and bandwith usage at server side…

    I dont know how really turboVNC works with multiclient connections… Same encoded desktop is sended to all clients? or are individual?
    I know that all ip sessions are independent (not multicast), but I dont know anything about the internal howto…

    Please what do you think coluld be the limit  for concurrent readonly clients, for i.e a tipical 2010 hardware (laptop intel core i5)?

    Thanks in advance…
    Probably I could test in some weeks… but some advices will be appreciated..

    One more thing…

    Any idea about give control of session to only one connected client (in session time)? (please dont tell me modify code…)

    Could be great a commandline server_control to do things like list connected, kill/pause/play one/all, give/take control to one… etc.

     
  • DRC
    DRC
    2012-01-12

    The state of high-speed Windows VNC Server solutions is somewhat sub-optimal, to be honest.  TurboVNC's version of WinVNC is pretty much a blind port of TightVNC 1.3.10, and although it's the fastest WinVNC I've tested, it also has a lot of serious functional issues (severe display artifacts when moving windows around, doesn't work on Vista or Windows 7, etc.)  It would require a complete re-architecture to fix those issues, and it would be much more within my sphere of expertise to just start over with the TightVNC 2.0.x code and apply the TurboVNC optimizations to it.  That, in and of itself, however, could likely turn into a 100-hour effort.

    TigerVNC is, functionality-wise, in better shape- it displays cleanly but unfortunately is 40% slower than TurboVNC.  The two solutions use identical encoding techniques, so the reasons for this slow-down are unknown.  Also, like TurboVNC, TigerVNC doesn't work on Vista or Windows 7.  UltraVNC is next in line, with full Vista and Windows 7 support but only 1/4 the performance of TurboVNC and banding artifacts on some applications (particularly video players or 3D apps.)  TightVNC 2.0.x has the best user interface, displays cleanly, and fully supports Vista and W7, but its performance is unusably slow.

    If I were wanting to move forward with a WinVNC solution in TurboVNC, I would bring in the TightVNC 2.0.x code and optimize it the same way I did TightVNC 1.3.x.  Given that the encoder in TightVNC 2.0.x is completely rewritten, however, this would be a pretty serious overhaul, probably in the range of 100 hours.  The other option is to fix the Vista/Windows 7 and performance issues in TigerVNC, which could easily take about the same amount of time, if not more.  I'd rather spend that time improving the Unix server, since that technology is actively used by VirtualGL.

    I mention all of this because of your comment "please don't tell me modify code."  Open source projects are driven by need.  The developers add features largely because either someone pays them to add the feature or because they need it themselves.  If there is not sufficient need for a feature within the open source community, a feature probably won't get added, or if it does get added, it probably won't be supported very well.  TurboVNC is driven by the need to have a high-speed X proxy on Linux servers.  Thus, the WinVNC portion is an afterthought.  It is somewhat vestigial in nature and may even go away in the next major release.

    To answer your specific questions:  there is currently no way to "pass around control" of the session, nor are there any plans for such a feature.  Either a client has control or it is view-only, and this is determined by the credentials it uses when logging in.

    WinVNC is a screen scraper, not a virtual desktop solution, so the same desktop image is sent to all connected clients.  The image has to be encoded separately for each connected client, because it is allowable for different clients to have different image quality settings, etc.

    For sending JPEG images with perceptually lossless image quality, you can count on each megapixel of encoding to take about 10-20 ms of CPU time.  Thus, with a single core, you could serve one client at 50-100 Mpixels/sec or 10 clients at 5-10 Mpixels/sec each.  The network bandwidth usage of course depends on the quality, but expect in the range of 1-2 bits/pixel for full-quality JPEG, half of that for medium quality, and 1/4 of that for low quality.

     
  • sega lion
    sega lion
    2012-01-16

    dcommander:

    Thanks for sharing your knowledge and your time.

    I havent tested TurboVNC server on Ms Vista/7, so its a bad new for me the "severe display artifacts when moving windows around". I have to think about … but maybe is easy for me forgive to move shared window
    I have detected that tooltips are missed (something about alpha blending options),

    The counts about CPU usage are very useful to me, but I probably have to make a real proof, because Im using the CPU to make other things simultaneously (sip voip sessions with the same number of participants (a meeting), making the PCM mix etc.)
    I will inform here about results…

    Its a pitty that turbovnc dont has an optimization to use same image and has to be encoded separately for each connected client (In my case all use same quality).

    The other things ( kill/pause/play one/all, give/take control to one… etc. ) probably I could make this outside VNC enviroment, (i.e. from server program, tell via INFO SIP to client program to kill vncclient read-only session, and create new one with full-access password….)

     
  • DRC
    DRC
    2012-01-16

    No version of VNC does the sort of multicasting you're referring to (distributing the same image to multiple clients.) VNC was designed as a client-driven system. Each client can request a new update from any part of the screen at any time using any type of encoding, and clients may be on different types of networks, so one may receive more updates than another.