xpra icon
Bug tracker and wiki

Opened 7 months ago

Last modified 33 hours ago

#1400 new enhancement

clipboard rate limit

Reported by: alas Owned by: alas
Priority: critical Milestone: 2.1
Component: clipboard Version: trunk
Keywords: Cc:

Description

Thinking about possible ways to handle the clipboard with html5 client, it might be useful to treat as a greedy client and sync with the primary clipboard. That said, users highlighting things left and right and so on might trigger some of the client lock ups that have been seen when clipboard sync'ing becomes overloaded.

It might also be useful to be able to set the rate limiting to include rate/size of content. (Or maybe not...)

Attachments (1)

throttle-clipboard.patch (3.8 KB) - added by Antoine Martin 3 months ago.
throttle the clipboard in the server source

Download all attachments as: .zip

Change History (9)

comment:1 Changed 7 months ago by Antoine Martin

Milestone: 2.0
Status: newassigned

Especially if "greedy" clients (ie: OSX, but maybe also the HTML5 client) sync with the PRIMARY clipboard.

comment:2 Changed 6 months ago by Antoine Martin

Priority: minormajor

This may also be useful for more gracefully handling clipboard managers, see ticket:276#comment:28.
Raising.

comment:3 Changed 5 months ago by Antoine Martin

Milestone: 2.02.1

Clipboard issues have only just been fixed, I am not feeling adventurous enough to make more changes just yet!

comment:4 Changed 4 months ago by Antoine Martin

This may also help with the html5 clipboard (#1461) since we synchronize the primary selection, which can get updated very rapidly.

Changed 3 months ago by Antoine Martin

Attachment: throttle-clipboard.patch added

throttle the clipboard in the server source

comment:5 Changed 3 months ago by Antoine Martin

The somewhat naive approach taken in the patch above found the following problems:

  • an earlier version failed to call "compress_clipboard" in the non-throttled case and caused the whole server to deadlock - not sure why, this shouldn't happen and needs investigating
  • this throttling does work but causes the packets to accumulate rapidly: easily queuing up hundreds of mostly useless packets

We should be smarter about where and how we throttle:

  • the "clipboard change" event usually triggers everything else
  • if we throttle it, maybe we need to also be able to cancel it when the token ownership changes... (using the token event counter)

comment:6 Changed 3 months ago by Antoine Martin

Owner: changed from Antoine Martin to alas
Status: assignednew

Done in r15603. We throttle the sending of the clipboard token.
The token is sent whenever:

  • the clipboard contents change and the client wants the updated contents, ie: "greedy" clients like macosx and html5
  • we didn't own the clipboard before and we need to tell the other end that we now do - this isn't throttled because it doesn't need to be (happens more rarely and would easily create race conditions if we did throttle it)

Ideally, we would only throttle the clipboard tokens when the sending is expensive (for "greedy" clients with the "want-targets" attribute), but this code throttles all "greedy" clients... including MS Windows clients. This could be improved.

By default the delay is 100ms (since r15604), tunable via the XPRA_DELAY_SEND_TOKEN env var.
I have kept the "more than XX clipboard requests per second!" guard that disables the clipboard with the same default

XPRA_CLIPBOARD_LIMIT=20, but it shouldn't be possible to trip this code with the default settings.

With "-d clipboard", the server log now shows:

(..)
clipboard: CLIPBOARD owner_changed, enabled=True, can-send=True, can-receive=True, have_token=False, greedy_client=True, block_owner_change=False
schedule_emit_token() elapsed=11
clipboard: CLIPBOARD owner_changed, enabled=True, can-send=True, can-receive=True, have_token=False, greedy_client=True, block_owner_change=False
clipboard: CLIPBOARD owner_changed, enabled=True, can-send=True, can-receive=True, have_token=False, greedy_client=True, block_owner_change=False
clipboard: CLIPBOARD owner_changed, enabled=True, can-send=True, can-receive=True, have_token=False, greedy_client=True, block_owner_change=False
send clipboard token: CLIPBOARD
(..)

The first "owner_changed" triggers "schedule_emit_token" and we have time to process 3 more "owner_changed" before we actually send the token.

To trigger those fast changes to the clipboard contents, you can select text in an editor (ie: gedit) and drag the mouse to change the selection, or you can use this shell scriptlet in an xterm:

while true; do
    date | xclip -selection CLIPBOARD -i;
    sleep 0.05;
done

@afarr: this works fine for me... not that this means much. Can you break it?

comment:7 Changed 33 hours ago by Antoine Martin

Priority: majorcritical

this is an important feature - please test

comment:8 Changed 33 hours ago by Antoine Martin

Summary: It might be useful to be able to set a clipboard rate limitclipboard rate limit
Note: See TracTickets for help on using tickets.