[
https://issues.apache.org/jira/browse/GUACAMOLE-1196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17906152#comment-17906152
]
Nick Couchman edited comment on GUACAMOLE-1196 at 12/16/24 7:08 PM:
--------------------------------------------------------------------
I ran a packet capture with resize both enabled and disabled, and here are the
results...
==Resize Disabled==
* Connection
* Authentication
* Share desktop flag sent to VNC server
* Server framebuffer parameters returned to client (guacd)
* Client set pixel format to VNC server
* Client set encoding to VNC server
* Client framebuffer update request to VNC server
* TCP ACK to client (guacd)
* TCP PUSH+ACK to client (guacd)
* Server framebuffer update to client (guacd)
* Client framebuffer update request to VNC server
* etc.
==Resize Enabled==
* Connection
* Authentication
* Share desktop flag to VNC server
* Server framebuffer parameters return to client (guacd)
* Client set pixel format to VNC server
* Client set encodings to VNC server
* Client framebuffer update request to VNC server
* TCP ACK to client (guacd)
* TCP PUSH+ACK to client (guacd)
* Unknown client message type (251) to VNC server -> 251 is rfbSetDesktopSize
* Unknown client message type (1) to VNC server -> 1 is CopyRect
* Client framebuffer update request to VNC server
* Server framebuffer update to client (guacd)
* RST+ACK to client (guacd) -> Connection dead.
It looks like maybe we're sending the initial resize message at the "wrong"
time - either when the VNC server isn't expecting it, or we're disrupting
something initially happening in the client <-> server handshake, where the
client has already sent an update message and is expecting to process a
response, but then we're telling the client to send something else and it's
getting confused on the replies?
Also, one thing that's unclear to me is why both rfbSetDesktopSize and copyRect
are seen as "unknown client message type[s]" - clearly they are documented and
known, and I'm reasonably certain that TightVNC supports desktop resizing??
was (Author: nick.couch...@yahoo.com):
I ran a packet capture with resize both enabled and disabled, and here are the
results...
==Resize Disabled==
* Connection
* Authentication
* Share desktop flag sent to VNC server
* Server framebuffer parameters returned to client (guacd)
* Client set pixel format to VNC server
* Client set encoding to VNC server
* Client framebuffer update request to VNC server
* TCP ACK to client (guacd)
* TCP PUSH+ACK to client (guacd)
* Server framebuffer update to client (guacd)
* Client framebuffer update request to VNC server
* etc.
==Resize Enabled==
* Connection
* Authentication
* Share desktop flag to VNC server
* Server framebuffer parameters return to client (guacd)
* Client set pixel format to VNC server
* Client set encodings to VNC server
* Client framebuffer update request to VNC server
* TCP ACK to client (guacd)
* TCP PUSH+ACK to client (guacd)
* Unknown client message type (251) to VNC server
* Unknown client message type (1) to VNC server
* Client framebuffer update request to VNC server
* Server framebuffer update to client (guacd)
* RST+ACK to client (guacd) -> Connection dead.
It looks like maybe we're sending the initial resize message at the "wrong"
time - either when the VNC server isn't expecting it, or we're disrupting
something initially happening in the client <-> server handshake, where the
client has already sent an update message and is expecting to process a
response, but then we're telling the client to send something else and it's
getting confused on the replies?
> Add auto resize to VNC sessions
> -------------------------------
>
> Key: GUACAMOLE-1196
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-1196
> Project: Guacamole
> Issue Type: Improvement
> Components: Documentation, VNC
> Reporter: Markus Bonet
> Assignee: Nick Couchman
> Priority: Minor
> Fix For: 1.6.0
>
>
> As discussed on the mailing list:
> {quote}
> I'm running a TigerVNC session on the server where Guacamole is installed. If
> I connect with the TigerVNC viewer there is this nice feature that the remote
> desktop is automatically resized if the viewer window is resized, like this
> if offered with RDP already.
> Is there a configuration how to achieve this with a Guacamole session as well
> for my VNC connection?
> {quote}
> Historically, this could not be done without corresponding support within
> libvncclient. This should now be possible through handling the required
> message type ({{SetDesktopSize}}):
> {quote}
> Unfortunately my team had to come up with a home baked solution for this
> about 2 years ago. But it involved hacking up libvnc.
> BUT, I think it is feasible to submit a feature request for it because now
> libvnc recently tagged a new version that includes the message type that
> guacamole needs to do this:
> Tag: https://github.com/LibVNC/libvncserver/releases/tag/LibVNCServer-0.9.13
> New message:
> https://github.com/rfbproto/rfbproto/blob/master/rfbproto.rst#setdesktopsize
> {quote}
> See:
> [http://apache-guacamole-general-user-mailing-list.2363388.n4.nabble.com/Auto-resize-of-VNC-sessions-td9511.html]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
