DRC <[email protected]> writes: > 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.
Great! I will try this. > > 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 -- Joakim Verona [email protected] +46705459454 ------------------------------------------------------------------------------ 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
