Hi Mike, Thanks you for your reply :) We are using Guacamole 1.0.0 (with intercepted streams). See my comments below.
Gabriel On Tue, 19 Nov 2019 at 21:26, Mike Jumper <[email protected]> wrote: > 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 > > Yes, but I don't think stream.sendEnd() is called when a file upload > finishes (at least I didn't find it, maybe I missed something). > > 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 > > I understand that, the reason I said it's not relevant is because we are > using the version with intercepted streams, and like you said the Java code > send the "end" instruction on behalf of the client, so the client doesn't > need to. Our fix is to extract the logic that frees the stream index from > endStream() to a new function and call this function in the "loadend" event > listener. > > 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? > > 1.1.0 > > Is this a known issue? > > > > No. > > Should I open a bug? > > > > 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. > > I tried the same only with MSTSC and the issue does not reproduce, I can > delete the file. I will try to analyze it and update. > > Why not connect using Guacamole directly to the machines in question, > rather than nest things? > > We use Guacamole as a web gateway to an RDP jump server which > automatically connects the user to another machine (it's a separate > product). > > - Mike >
