RDP Drive Redirection

[gabriel sztejnworcel <ga...@gmail.com>]

Hi,

We would like to use the RDP drive redirection capability of Guacamole. We
do not use the full web application, we've built a (relatively) simple web
application around Guacamole-Common, so we don't have the this
capability built-in. In the Guacamole web application, the upload/download
of files involve a separate HTTP call to a service which intercepts the
connection tunnel and sends the data to the server on behalf of the client
and vice versa. We could do something similar, but it introduces some
challenges (which are mostly related to the specific way we use Guacamole).
We thought of a different approach, instead of a separate HTTP call and the
stream interception, we would do everything on the client side using
JavaScript. For example, to upload a file, we would use the FileReader API
to read parts of the file and send it directly as blob instructions from
the client. To download a file, we would send the first ack from the
client, then receive the blob instructions from the server, and use the
StreamSaver library to create a download stream. We have already managed to
upload files successfully that way, but the latency is bad.

My first question is regarding our approach in general, do you see any
issues with it? What was the main reason for implementing upload and
download with the stream interception mechanism?

The second question is regarding the latency. Guacamole instructions are
limited to 8192 bytes, which means that for large files we would have a
huge amount requests and responses, which really affects the total latency.
Is increasing the 8192 limit an option? Or will it causes more problems?
Any other ideas to overcome this issue?

Thanks,
Gabriel

Re: RDP Drive Redirection

[gabriel sztejnworcel <ga...@gmail.com>]

Thanks Richard, great information :)
I looked at the issue and checked the code before the fix. For downloads,
they are using FileSaver, which has to hold the entire file in memory
before saving it, and for uploads they are using FileReader like we did,
but they read the entire file before splitting it for the blob
instructions. For downloads we would like to use StreamSaver, which claims
to work without holding the entire file in memory, and for uploads we can
read a part of the file each time.
It's been more than 3 years since this issue was resolved, maybe back then
the APIs/libraries were not available.
I'm encouraged by this information, if that was the reason for the change
then I think our solution is valid.
What about the latency issue? Any thoughts on that? I saw that there is a
"nest" instruction, which is something like grouping multiple together. Is
it possible to overcome the 8192 limit with nest?

On Mon, 9 Sep 2019 at 15:51, Richard Lancaster <
richard.lancaster@osirium.com> wrote:

> I don't work for the project, but was thinking about the same problem
> recently.
>
> (As far as I am aware) The project used to do exactly what you describe,
> but was removed for this reason:
> https://issues.apache.org/jira/projects/GUACAMOLE/issues/GUACAMOLE-44?filter=allissues
>
> Thanks,
> Richard
> ------------------------------
> *From:* gabriel sztejnworcel <ga...@gmail.com>
> *Sent:* 09 September 2019 12:53
> *To:* user@guacamole.apache.org <us...@guacamole.apache.org>
> *Subject:* RDP Drive Redirection
>
> Hi,
>
> We would like to use the RDP drive redirection capability of Guacamole. We
> do not use the full web application, we've built a (relatively) simple web
> application around Guacamole-Common, so we don't have the this
> capability built-in. In the Guacamole web application, the upload/download
> of files involve a separate HTTP call to a service which intercepts the
> connection tunnel and sends the data to the server on behalf of the client
> and vice versa. We could do something similar, but it introduces some
> challenges (which are mostly related to the specific way we use Guacamole).
> We thought of a different approach, instead of a separate HTTP call and the
> stream interception, we would do everything on the client side using
> JavaScript. For example, to upload a file, we would use the FileReader API
> to read parts of the file and send it directly as blob instructions from
> the client. To download a file, we would send the first ack from the
> client, then receive the blob instructions from the server, and use the
> StreamSaver library to create a download stream. We have already managed to
> upload files successfully that way, but the latency is bad.
>
> My first question is regarding our approach in general, do you see any
> issues with it? What was the main reason for implementing upload and
> download with the stream interception mechanism?
>
> The second question is regarding the latency. Guacamole instructions are
> limited to 8192 bytes, which means that for large files we would have a
> huge amount requests and responses, which really affects the total latency.
> Is increasing the 8192 limit an option? Or will it causes more problems?
> Any other ideas to overcome this issue?
>
> Thanks,
> Gabriel
>

Re: RDP Drive Redirection

[Richard Lancaster <ri...@osirium.com>]

I don't work for the project, but was thinking about the same problem recently.

(As far as I am aware) The project used to do exactly what you describe, but was removed for this reason: https://issues.apache.org/jira/projects/GUACAMOLE/issues/GUACAMOLE-44?filter=allissues

Thanks,
Richard
________________________________
From: gabriel sztejnworcel <ga...@gmail.com>
Sent: 09 September 2019 12:53
To: user@guacamole.apache.org <us...@guacamole.apache.org>
Subject: RDP Drive Redirection

Hi,

We would like to use the RDP drive redirection capability of Guacamole. We do not use the full web application, we've built a (relatively) simple web application around Guacamole-Common, so we don't have the this capability built-in. In the Guacamole web application, the upload/download of files involve a separate HTTP call to a service which intercepts the connection tunnel and sends the data to the server on behalf of the client and vice versa. We could do something similar, but it introduces some challenges (which are mostly related to the specific way we use Guacamole). We thought of a different approach, instead of a separate HTTP call and the stream interception, we would do everything on the client side using JavaScript. For example, to upload a file, we would use the FileReader API to read parts of the file and send it directly as blob instructions from the client. To download a file, we would send the first ack from the client, then receive the blob instructions from the server, and use the StreamSaver library to create a download stream. We have already managed to upload files successfully that way, but the latency is bad.

My first question is regarding our approach in general, do you see any issues with it? What was the main reason for implementing upload and download with the stream interception mechanism?

The second question is regarding the latency. Guacamole instructions are limited to 8192 bytes, which means that for large files we would have a huge amount requests and responses, which really affects the total latency. Is increasing the 8192 limit an option? Or will it causes more problems? Any other ideas to overcome this issue?

Thanks,
Gabriel