I have two more questions :-)
1. Does guacamole support RemoteFX?
Guacamole seems to use FreeRDP, which does. Yet, there is an open ticket which indicated that someone wrote a piece of code for activating RemoteFX support a few years ago, but did not commit it (https://glyptodon.org/jira/browse/GUAC-721). Is this still the case - or does it work now? :-) If so, what to do?
There are a few other threads asking the same question:
2012 (but on FreeRDP issue board ;-): https://github.com/FreeRDP/FreeRDP/issues/772
2. Does guacamole support sharing sessions?
E.g., one user opening a VNC/RDP session between client -> guacamole -> vnc/rdp server, then another one joining in (client -> guacamole, but no new connection between guacamole -> vnc/rdp server). The reason is, that while VNC supports multiple simultaneous clients, that drains performance if the host is not well connected, while RDP does not seem to support multiple connections.
On Wed, Jun 7, 2017 at 11:57 AM, Herzog <[hidden email]> wrote:
> Hello together,
> I have two more questions :-)
> 1. Does guacamole support RemoteFX?
No, this is not implemented.
> Guacamole seems to use FreeRDP, which does. Yet, there is an open ticket
> which indicated that someone wrote a piece of code for activating RemoteFX
> support a few years ago, but did not commit it
> (https://glyptodon.org/jira/browse/GUAC-721). Is this still the case - or
> does it work now? :-) If so, what to do?
JIRA tickets get closed when features are implemented, so the fact
that this issue is open is a good indicator that the support is
absent. The JIRA instance you point to in this case is the JIRA
instance that the project used prior to moving to the Apache
Incubator, so it's possible that issues which have been addressed
upstream are not up-to-date there, but if a search of the Apache JIRA
reveals no such issues, and the issue in the old JIRA is still open,
it's probably safe to say it has not been addressed. Changes simply
aren't made to Guacamole without a corresponding issue in JIRA.
Regarding the code you refer to, the problem there is that the author
of those patches did not give permission to include his modifications
(they were provided back when the project was MIT-licensed), did not
specify the license under which his modifications released, and did
not respond to requests for permission to build off those
modifications. All that, plus the poor quality of that particular
piece of code, means that potential contribution is likely a
non-starter. It'd be nice if we could get his permission and would
work with him to address the quality issues ... but there's
unfortunately nothing we can do with those patches without his
Adding support for RemoteFX is possible, but we will have to start
from scratch, ignoring those patches.
> 2. Does guacamole support sharing sessions?
Yes, since 0.9.10-incubating:
This post was updated on .
Would it be sufficient to keep an instance of the initial ConfiguredGuacamoleSocket, e.g. in a Map and return a new instance of SimpleGuacamoleTunnel(existingConfiguredSocket)?
I just found the following in the docs:
This supports the hypothesis that a new tunnel is needed. :)
On Wed, Jun 7, 2017 at 12:58 PM, Herzog <[hidden email]> wrote:
> Would it be sufficient to keep an instance of the initial
> ConfiguredGuacamoleSocket, e.g. in a Map and return a new instance of
Can you describe what you're trying to do?
Guacamole already supports screen sharing. Unless you're writing an
extension, or trying to use that support in different webapp that
you're developing yourself using the Guacamole API, there's no need to
make any code changes. Everything is already there.
This post was updated on .
yes, of course!
I am trying to integrate Guacamole into my bachelor thesis project (a web app of it's own).
I already have user authentication and because I would like to have a seamless integration of a "Remote Desktop" feature within my web app, using the existing Guacamole web app did not make sense.
That's why my starting point was the excellent tutorial
I now have a GuacamoleHTTPTunnelServlet - basically as described in the tutorial, just with more config options, as well as a WebSocket equivalent and both ways to do Guacamole work impressively well.
I am now trying to implement a session sharing feature. And after stumbling across another code of yours, I would try the following for all but the first clients:
Does that sound about right? :)
On Wed, Jun 7, 2017 at 1:58 PM, Herzog <[hidden email]> wrote:
> I am trying to integrate Guacamole into my bachelor thesis project (a web
> app of it's own).
> I am now trying to implement a session sharing feature. And after stumbling
> across another code of yours, I would try the following for all but the
> first clients:
>> GuacamoleConfiguration config = new GuacamoleConfiguration();
>> GuacamoleSocket socket = new ConfiguredGuacamoleSocket(new
>> InetGuacamoleSocket(guacamoleHost, guacamolePort), config);
> Does that sound about right?
Yes. As long as previouslyStoredId is the ID value from
getConnectionID() of the ConfiguredGuacamoleSocket for the connection
being joined, and guacamoleHost and guacamolePort are the hostname and
port of the instance of guacd used for the connection being joined,
this should work fine.
Thanks a lot!
I'm a little confused. Isn't remotefx a strictly (or mainly) server side solution, so that so long as we enable remotefx on the WinServer 2016 server, all we need is a "plain old" rdp client (eg normal guacamole) and it should work? That is, does remotefx not work just like vnc-like solutions and transmit the computed bitmap image back to the rdp client, so the rdp client need not have any code changes? The reason I ask this is twofold: one, there doesn't appear to be any specific requirement for the rdp client to support remotefx, though the documentation is a touch confusing on this regard. And two, thinrdp seemed to support remotefx years ago, and I have a hunch they never recoded anything. (Note: In our use case, we are only using remoteFx to use the 3d accelerated NVidia graphics card that is on the winserver 2016 vm running on the google cloud; we don't care about USB redirection etc.)
If the rdp client (eg guacamole in this case) really must change in order to "view" remoteFx enabled screens, then what about simply installing a vnc server (such as TightVNCServer or RealVNC Server or UltimateVNC Server on the Win Server 2016 VM) and then using guacamole to connect to the win machine via vnc? (I believe that vnc will still allow the WinServer machine to use the NVidia graphics card, and I believe that guacamole shouldn't have any trouble at that point, since presumably vnc is just sending bitmap images back?)
Lastly, if none of the above ideas work (or work well), would there be interest in all the people on this thread and any others that have desired remoteFx support in guacamole to maybe band together and sponsor this feature (so it's done sooner rather than later)? We're a tiny company (1 founder + 5 part-time developers, but I'm sure we can help.)
On Tue, Jul 11, 2017 at 9:52 AM, Jonathan Swift <[hidden email]> wrote:
I'm a little confused. Isn't remotefx a strictly (or mainly) server side
Nope. RemoteFX uses entirely different codecs to transmit the image. Though FreeRDP supports those formats, Guacamole would need to be modified to implement and call the appropriate functions to shuttle the RemoteFX data back and forth, updating its own internal surface with the received data.
The main barrier here is the total lack of API docs on the FreeRDP side, but it's doable.
The reason I ask this is twofold:
They would need to explicitly handle the RemoteFX data. There is no other way.
Yes, you can do this.
Lastly, if none of the above ideas work (or work well), would there be
You can't directly sponsor development here - we're strictly volunteers. You can donate to the ASF - it will not influence project decisions or what features get developed, but don't let that stop you. ;)
Development is supported through contributions of code, which are always made by individuals. You can definitely contribute if you have the development bandwidth to do so, or even hire a third party to contribute, but you cannot hire the project. As long as it's an individual contributing the changes, and as long as that individual can legally do so, there's no problem, since it's still that group of volunteers that ultimately decides how/if that contribution is accepted, independent of corporate influence.
This post was updated on .
I would be more than interested, too!
Mike, is the MIT licensed "poorly implemented" version publicly available? Could you publicize it otherwise?
Maybe we could use that as a starting point (regarding the lack of documentation, some code would surely help).
On Fri, Jul 21, 2017 at 6:01 AM, Herzog <[hidden email]> wrote:
> I would be more than interested, too!
> Mike, is the MIT licensed "poorly implemented" version publicly available?
> Could you publicize it otherwise?
No, this is incorrect.
If it were MIT-licensed, yes, we could indeed do as you suggest. The
main reason the code cannot be used is because its license status is
unknown. The author made his changes to MIT-licensed code, yes, but
that does not mean his changes are under the same license. Without the
explicit permission of the author, and without a license giving us
permission, we cannot legally include his code.
> Maybe we could use that as a starting point (regarding the lack of
> documentation, some could would surely help).
The only legal route is to start from scratch, without referencing his
code in any way whatsoever. Doing otherwise risks creating a
derivative work and running afoul of copyright law.
It would be safe to consult the FreeRDP source itself, particularly
the X11 client implementation. In fact, since FreeRDP has no API
documentation, walking through the code is very often the only way to
determine what the various functions/parameters/structures actually
do. It's fairly painful, but it is doable, and in this case it's
simply the only option.
|Free forum by Nabble||Edit this page|