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
--
Joakim Verona
------------------------------------------------------------------------------
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
