On Tue, Nov 19, 2019 at 8:50 AM gabriel sztejnworcel <[email protected]> wrote:
> Hi, > > We would like to start using RDP file transfer. We found some issues I > would like to discuss: > > 1. After uploading 64 files in one session (not on the same time), the next > uploads fail with an "Invalid stream index" error. I found that the max > stream index is 64, and the client holds a pool of stream indices for the > uploads. The problem is that it does not mark an index as free when an > upload finishes. There is a function that does this - endStream(), but it's > not called (the function also sends an "end" instruction which I don't > think is relevant in this case). It's called by sendEnd() in Guacamole.OutputStream and is critical for streams that are managed by the JavaScript client (not streams intercepted by the webapp - see below): https://github.com/apache/guacamole-client/blob/062edda07b7759d3a86a9a8b476d03eb8a4aeda1/guacamole-common-js/src/main/webapp/modules/OutputStream.js#L61-L66 The "end" instruction is also critical. The server needs to be informed when the stream is ending so it can free resources, take any actions required by the underlying remote desktop protocol when transfers are completed, etc. When a client-side stream is not used within JavaScript, but is intercepted within the webapp (used by the mainline Guacamole webapp), it would be on the webapp to send this instruction on behalf of the user, as is done here: https://github.com/apache/guacamole-client/blob/c890919d5bbb9ccc8243f04caae07c78a032ef07/guacamole/src/main/java/org/apache/guacamole/tunnel/InputStreamInterceptingFilter.java#L82-L92 https://github.com/apache/guacamole-client/blob/c890919d5bbb9ccc8243f04caae07c78a032ef07/guacamole/src/main/java/org/apache/guacamole/tunnel/InputStreamInterceptingFilter.java#L112-L121 We solved this in our repo by freeing the index when receiving the > "loadend" event from the upload ajax call. What version of Guacamole are you using? Is this a known issue? > No. > 2. Uploading more than 64 on the same time is not possible due to the max > streams limit. We would like to solve it by creating a queue of pending > file uploads on the client side. Does this make sense? > Yes. 3. The following scenario: > > a. Connect to an end point using Guacamole with drive redirection. > b. Assign a drive letter to the redirected drive/folder. > c. MSTSC to another machine with drive redirection. > d. The Guacamole redirected folder appears on the second machine and > uploaded files can be accessed, but when we delete a file (from within the > nested RDP session), the file is not deleted. It disappears from file > explorer, but appears again upon refresh. It is not deleted from the > Guacamole machine. We reproduced the issue on Windows Server 2012 R2 and > Windows Server 2016 targets (for the nested RDP session), on Windows Server > 2008 R2 it didn't reproduce, delete worked as expected. > > Any ideas on what can be the reason for this behavior? I know it seems like > an esoteric use case, but it's actually our main flow so it's important for > us to solve it. I'm not sure what could cause this. The first step would be to confirm that the issue is specific to Guacamole by trying the same through MSTSC. If this is confirmed, then it may be that there are filesystem operations that MSTSC depends on for drive forwarding but which are not implemented. The logs from guacd may help. Why not connect using Guacamole directly to the machines in question, rather than nest things? - Mike
