The pre-release builds now have this feature. To use it, start the server with -disconnect. Then when you start a viewer instance with -noshared, it will disconnect all others.
On 12/8/16 2:34 PM, [email protected] wrote: > DRC <[email protected]> > writes: > >> Can you explain more about your particular use case? The typical use >> case for TurboVNC is that you have a "primary" connection-- that is, a >> connection from the owner of the TurboVNC session-- and you have >> secondary connections from "collaborators", but it sounds like your use >> case may be different than that. > > Thanks for your exhaustive reply! I will read it thoroughly, but I will > explain my usecase first. > > I have been using x2go a lot over the years, but recently I have started > migrating to turbovnc. > > x2go works by default that you only have one client connected. If you > connect with a new client, the other client on another machine is > disconnected. This is okay, but it takes some time to switch to another > machine, which I do frequently enough for it to be annoying. > > What I wanted to do with my new shiny turbovnc setup was to have several > viewers running, on the machines I normally use. Then I would just have > to resize the turbovnc window to the size of the screen on the current > machine. > > I would be fine with just having the new viewer kick out the old > viewers, like x2go works. Turbovnc is much faster to connect than x2go > anyway. > > > > > >> >> It is certainly possible to force only one connection at a time by >> disabling session sharing. There are three server-side options that >> control sharing: -dontdisconnect, -alwaysshared, and -nevershared. >> They work as follows: >> >> {none of the options}: >> NOTE: This is not actually possible in TurboVNC without editing the >> vncserver script, because that script is hard-coded to pass >> -dontdisconnect to Xvnc. I've personally never found the behavior of >> the server without -dontdisconnect useful, but if someone else does, >> then we can certainly make that behavior available without editing the >> vncserver script. >> NOTE: This is the default behavior in TigerVNC and RealVNC. >> >> If a new viewer authenticates and connects successfully without >> "shared session" enabled in the viewer settings, then all existing >> viewers are disconnected. (Yeah, that's why I don't find this option >> useful. It's rather disconcerting if you're working in a VNC session >> and it suddenly goes away because someone else connected.) >> >> -dontdisconnect: >> NOTE: This is the default behavior in TurboVNC. >> >> If a new viewer authenticates and connects successfully without >> "shared session" enabled in the viewer settings, then the new viewer is >> immediately disconnected. >> >> -alwaysshared: >> The "shared session" setting from viewers is ignored, and all of them >> are treated as if they have "shared session" enabled. Thus, no viewer >> is ever disconnected when a new viewer connects. >> >> -nevershared: >> NOTE: This is not actually possible in TurboVNC without editing the >> vncserver script, because that script is hard-coded to pass >> -dontdisconnect to Xvnc. >> >> The "shared session" setting from viewers is ignored, and all of them >> are treated as if they have "shared session" disabled. Thus, if a new >> viewer authenticates and connects successfully, then all existing >> viewers are disconnected. >> >> -nevershared -dontdisconnect: >> The "shared session" setting from viewers is ignored, and all of them >> are treated as if they have "shared session" disabled. Thus, if a new >> viewer authenticates and connects successfully, then it is immediately >> disconnected. >> >> >> As far as remote desktop resizing, it is possible to achieve what you >> want manually, but it would require that the client with the smaller >> screen voluntarily switch off automatic desktop resizing before the >> larger-screen client connects. The basic problem with trying to enforce >> any automatic behavior, other than the current behavior, is that the >> server doesn't know what size the client screens are, nor does it know >> which viewer should be given precedence over the others. Thus, it >> currently treats all viewers as equal. It would be straightforward to >> treat one viewer as the "primary" viewer and ignore remote desktop >> resize requests from the other viewers, but there would be no way of >> giving a viewer precedence based on its client screen size, because the >> server doesn't have that information. The best we could do is to either >> give precedence to the first connection or to the most recent >> connection. At the moment, the only way that the server has of >> differentiating between primary and secondary connections is the >> view-only setting. If a client authenticates using view-only >> credentials (either a view-only VNC password or OTP token, or PAM >> credentials that were added to the TurboVNC session's view-only ACL), >> then the server could easily ignore remote desktop resize requests from >> such clients, but of course those clients would not be allowed to send >> keyboard or mouse events. Perhaps there needs to be a third set of >> credentials called "collaborate-only"? That is certainly >> straightforward to implement, but I would need more information about >> what exactly you are trying to achieve. >> >> What happens now: >> >> When the larger-screen client connects with automatic desktop resizing >> enabled, it sends a desktop resize request to the server to attempt to >> make the server's desktop fit in the viewer's window without using >> scrollbars. The server honors the request and sends out a desktop >> resize message to all connected viewers. The smaller-screen client >> attempts to resize its window to accommodate the new larger desktop >> size. It figures out that it can't do that without using scrollbars, so >> it resizes its window to the largest size it can accommodate without >> scrollbars, and it sends back a desktop resize request to the server. >> The server honors this new request, which shrinks the desktop back to >> its old size, and the new (old) size is sent back to the larger-screen >> viewer. In order to prevent an infinite loop, the viewers always accept >> a new remote desktop size from the server if it is smaller than their >> maximum window size. They only try to "fight the system" if the remote >> desktop size is bigger than their maximum window size. Basically, the >> current viewer behavior is designed such that no viewer with automatic >> desktop resizing enabled will ever have scrollbars, but that requires >> that all viewers shrink their windows to accommodate the client with the >> smallest screen. >> >> >From the server's point of view, it doesn't know whether a remote >> desktop resize request was due to automatic desktop resizing or whether >> the viewer was trying to manually set the remote desktop size. From the >> viewer's point of view, however, it does know whether a remote desktop >> resize was triggered by another viewer, so conceivably, the behavior >> could be changed such that a viewer accepts remote desktop resizes from >> other viewers without question. However, this would only be a >> meta-stable state. As soon as a viewer window size changes, it would >> trigger a new desktop resize request to the server, and that would cause >> the same sequence of events described above, resulting in the >> larger-screen clients having to accept a smaller-than-optimal desktop >> size. The only way to avoid this is to assign some kind of precedence >> order to the viewers and enforce it on the server, but per above, that >> precedence order unfortunately can't be based on the client screen size. >> >> >> On 12/8/16 4:31 AM, [email protected] wrote: >>> Scenario: >>> - One server running turbovnc >>> - One client connects to the server, with a fairly low-res screen. So >>> far so good. >>> - Another client with a better screen connects to the same server, and vnc >>> session. The >>> connection works, but its not possible to enlarge the vnc window to fit >>> the larger physical screen on the new client. The window is >>> automatically downsized to the size of the smallest connected client. >>> >>> How can I solve this? Several options would be acceptable: >>> - the remotes that have too small screen could be scaled to fit >>> automatically >>> - they could be kicked out of the vnc session >>> - they could simply get resized windows that are larger than the >>> physical screen. >>> >>> Any hints how to solve this would be apreciated! >> >> ------------------------------------------------------------------------------ >> Developer Access Program for Intel Xeon Phi Processors >> Access to Intel Xeon Phi processor-based developer platforms. >> With one year of Intel Parallel Studio XE. >> Training and support from Colfax. >> Order your platform today.http://sdm.link/xeonphi ------------------------------------------------------------------------------ Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today.http://sdm.link/xeonphi _______________________________________________ TurboVNC-Users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/turbovnc-users
