general functioning of guacamole

[Galyrith <qu...@umontpellier.fr>]

Hello,

I have some questions about the general functioning of guacamole.

So, I am trying to implement it in the structure where I am, but I am asked
for something of a general nature.
If I understand correctly how Guacamole works is between the web browser and
the remote client and it is guacd that allows the link between the two.

So I have two questions:
1 / How does guacd manage this translation? does he compress the flow or
not?
2 / How much data and how is it managed by the web browser?

Thank you for your response and your time



--
Sent from: http://apache-guacamole-general-user-mailing-list.2363388.n4.nabble.com/

Re: general functioning of guacamole

[Galyrith <qu...@umontpellier.fr>]

Thanks for the information.
I understand better the operation to be able to use it in the best.



--
Sent from: http://apache-guacamole-general-user-mailing-list.2363388.n4.nabble.com/

Re: general functioning of guacamole

[Mike Jumper <mj...@apache.org>]

On Fri, Oct 5, 2018 at 1:42 AM, Nick Couchman <vn...@apache.org> wrote:

> On Fri, Oct 5, 2018 at 4:04 AM Galyrith <qu...@umontpellier.fr>
> wrote:
>
>> ...
>
>
>> So I have two questions:
>> 1 / How does guacd manage this translation? does he compress the flow or
>> not?
>>
>
> guacd attempts to do some analysis of the link between itself and
> Guacamole Client to determine the best image type to send.  I believe it
> uses a combination of JPEG and PNG, but Mike can probably provide more
> accurate information on this.  Obviously JPEGs will be compressed, and PNGs
> may be compressed.  The rest of the stream (commands, keystrokes, etc.) is
> not compressed.  I'm not sure about the audio.
>

All images sent via Guacamole are compressed - JPEG and PNG are simply two
different compressed image formats, the former being lossy and the latter
being lossless. The internals of guacd will dynamically determine whether
JPEG or PNG is likely to perform better and select automatically between
the two. Only the changed portion of the screen is sent with each update,
though Guacamole will also dynamically reorder, combine, etc. these updates
in an effort to optimize things further.

Timing of updates is also dynamically adjusted based on real-time
measurements of how long each frame takes to generate and how fast the
client is able to process each frame. This is meant to allow Guacamole to
distinguish between time delay due to pure network lag vs. time delay due
to the client being slower than the server, allowing Guacamole to send
updates asynchronously and optimistically.


>
>> 2 / How much data and how is it managed by the web browser?
>>
>
>
In practice, I see typically around 1 or 2 Mbps during normal remote
desktop use. This can go up to around 10 Mbps if you do something rather
intense like watch YouTube.

- Mike

Re: general functioning of guacamole

[Galyrith <qu...@umontpellier.fr>]

Thank you for that answer.
I understand better now.



--
Sent from: http://apache-guacamole-general-user-mailing-list.2363388.n4.nabble.com/

Re: general functioning of guacamole

[Nick Couchman <vn...@apache.org>]

On Fri, Oct 5, 2018 at 4:04 AM Galyrith <qu...@umontpellier.fr>
wrote:

> Hello,
>
> I have some questions about the general functioning of guacamole.
>
> So, I am trying to implement it in the structure where I am, but I am asked
> for something of a general nature.
> If I understand correctly how Guacamole works is between the web browser
> and
> the remote client and it is guacd that allows the link between the two.
>

Well, kind of.  The web browser does not directly interact with guacd.  The
web browser interacts with the Java application (Guacamole Client) running
in Tomcat.  That Java application translates between the web browser
(HTTP(S)/WS(S)) and the Guacamole Protocol.  The Guacamole Server (guacd)
translates between the Guacamole Protocol requests coming in from Guacamole
Client(s) and the remote desktop protocol.  My legendary skills in drawing
diagrams (</sarcasm) lead to this:

Web Browser <-- HTTP(S)/WS(S) Protocol --> Guacamole Client
(Tomcat/JBOSS/etc.) <-- (Guacamole Protocol) --> guacd <--
(RDP/SSH/Telnet/VNC) --> Remote Desktop Server


>
> So I have two questions:
> 1 / How does guacd manage this translation? does he compress the flow or
> not?
>

guacd attempts to do some analysis of the link between itself and Guacamole
Client to determine the best image type to send.  I believe it uses a
combination of JPEG and PNG, but Mike can probably provide more accurate
information on this.  Obviously JPEGs will be compressed, and PNGs may be
compressed.  The rest of the stream (commands, keystrokes, etc.) is not
compressed.  I'm not sure about the audio.


> 2 / How much data and how is it managed by the web browser?
>

"How much data" is a very open-ended question that doesn't really have a
single answer, aside from "that depends."  It depends on things like:
- The resolution of the client web browsers (image size)
- Whether you're doing audio or not, and how much audio
- Whether you're doing file transfers or not, what types of files, and how
frequently
- Whether you're doing printing or not, what types of printing, and how
frequently
- What remote protocol you're using (SSH/Telnet vs. RDP vs. VNC)
- How many concurrent users and connections you have or expect to have
- The length of the sessions

For the "how is it managed by the web browser" part of this question, I'm
not sure what you mean?  The browser interacts with the Guacamole Client
Java application the same way it interacts with any other HTTP/WS server -
there's not any special data management on the part of the web browser
that's specific to Guacamole.

-Nick