[
https://issues.apache.org/jira/browse/GUACAMOLE-1214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17234831#comment-17234831
]
Mike Jumper commented on GUACAMOLE-1214:
----------------------------------------
{quote}
Mike can probably fill in the history on that, but my speculation is that it
wasn't required for the basic clipboard functionality as currently implemented.
{quote}
The main need for the "ack" is to allow the server to communicate I/O failures
and to limit the transfer rate of data. The protocol leaves whether an "ack" is
actually sent up to the implementation of the recipient of the data. In
practice, both server and client have to keep in mind whether "ack" is
appropriate/required.
The protocol says only that it _should_ be sent, and it _should_ be unless
there is a specific reason not to.
{quote}
But I prefer to follow the logic of the current clipboard feature.
{quote}
I don't think this is really a matter of preference; it's a matter of whether
the technical need exists. If the "ack" is needed for binary clipboard data, it
should be sent. It shouldn't _not_ be sent purely because it's not currently
how things are done for text.
If you truly believe the best path forward is to allow {{Guacamole.BlobWriter}}
to work without waiting for an "ack", you would need to modify
{{Guacamole.BlobWriter}} such that this behavior can be altered, presumably
through some flag that can be sent by the user of the class. It definitely
shouldn't be modified to just never wait for the "ack" at all.
Beware that:
* _Not_ waiting for the "ack" could cause problems for large amounts of data
for tunnel implementations that buffer outbound data (the HTTP tunnel). The
outbound send buffer may fill up with essentially the entire stream, which the
browser may not be able to handle.
* The sheer amount of "blob" instructions sent may result in an excessive
amount of outbound bandwidth being devoted to binary data transfer rather than
user interaction, causing the connection to feel unresponsive.
It is definitely not a bug. This is the intentional behavior of the current
implementation and the matter-of-fact requirements of the protocol. If you want
to move forward with changes that allow {{Guacamole.BlobWriter}} to not wait
for "ack" messages, I suggest making those changes as part of the development
of image copy/paste or as an improvement to {{Guacamole.BlobWriter}}.
> When sending data more than 6048 bytes, the readNextChunk() function is
> called only once in BlobWriter.sendBlob()
> -----------------------------------------------------------------------------------------------------------------
>
> Key: GUACAMOLE-1214
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-1214
> Project: Guacamole
> Issue Type: Bug
> Components: guacamole-client
> Affects Versions: 1.2.0
> Reporter: Jimmy
> Priority: Major
> Attachments: image-2020-11-17-09-25-16-947.png,
> image-2020-11-17-09-27-14-470.png
>
>
> Because I need to investigate the solution of the copy/paste of an image, I
> modified some code related to the clipboard.
> When I click the guacamole client page after copy the image, the
> ManagedClient.setClipboard() function is called to send the blob of the image
> to the guacamole server.
> !image-2020-11-17-09-25-16-947.png!
> When the size of data to be sent is more than 6048 bytes, the readNextChunk()
> function is called only once in BlobWriter.sendBlob().
> Because arrayBufferWriter.onack() isn't called.
> !image-2020-11-17-09-27-14-470.png!
> So, only the 6048 bytes are sent in the whole data.
>
> I think that to directly call readNextChunk() after call of
> arrayBufferWriter.sendData() in chunkLoadComplete() of BlockWriter.js may be
> a solution.
>
> Please help.
> Thanks.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
