xpra icon
Bug tracker and wiki

Opened 11 months ago

Closed 9 months ago

Last modified 9 months ago

#1688 closed enhancement (fixed)

warning notifications

Reported by: Antoine Martin Owned by: Antoine Martin
Priority: major Milestone: 2.3
Component: client Version: trunk
Keywords: Cc:

Description (last modified by Antoine Martin)

If something goes wrong, the message ends up in the console output and server log (via remote logging), but most users won't look there and will therefore be unaware of the problem.

We should add an option to allow notifications to be used for major events, ie: another user joined the session, file uploads (#1375), the connection is having problems (#401)

The initial warnings during the client startup could be bunched up together to avoid spamming the notification system with multiple messages on startup.
In any case, this should probably be rate limited and controllable from the system tray menu.

Links:

See also: #1492, #1305

Change History (9)

comment:1 Changed 11 months ago by Antoine Martin

Description: modified (diff)
Status: newassigned

comment:2 Changed 11 months ago by Antoine Martin

Milestone: 3.02.3

comment:3 Changed 9 months ago by Antoine Martin

Large change in r18110: refactoring + a user joining the session will trigger a notification message sent to:

  • all other connected users for seamless sessions
  • the session itself for shadow sessions

Still TODO:

  • tie the notification to our tray (on win32)
  • send notifications to the user whose connection is having problems (congestion events), rate limited
  • maybe file uploads - though #1375 already provides a dialog..

comment:4 Changed 9 months ago by Antoine Martin

  • r18111 + r18113: the notifications are now tied to our system tray on win32
  • r18116: refactoring preparation for bandwidth congestion warnings

Still TODO:

  • better bandwidth congestion detection: the heuristics may be improved (detecting late acks) and this should fire the "congestion" handling code
  • maybe add a way for us to intercept the notification "action" response, so we can fire code server side?

comment:5 Changed 9 months ago by Antoine Martin

comment:6 Changed 9 months ago by Antoine Martin

Owner: changed from Antoine Martin to J. Max Mena
Status: assignednew
  • mostly done for bandwidth issues in r18194 (#401 closed as a duplicate of this bug): when we detect multiple network congestion events (more than XPRA_CONGESTION_WARNING_EVENT_COUNT=10 in the last 10 seconds) we send a notification to the client with an optional action to lower the bandwidth limit. We use #1676 to keep things in sync with the client, works for "bandwidth-limit", adding support for changing the "min-quality" using a notification action would require a bit more work.

The new "-d bandwidth" debug switch can be used to see how we try to manage the bandwidth.

From now on, we can easily add more warning notifications as we go along.


To test:

  • XPRA_ACK_TOLERANCE=0 may be enough to go over the threshold, or lower XPRA_CONGESTION_WARNING_EVENT_COUNT, and/or use a bandwidth limiter (see #417), then generate lots bandwidth (ie: glxspheres): notification allows the client to lower the bandwidth limit (unless it is already so low it cannot be lowered)
  • enable sharing and connect with more than one client: notification shows details about the new user connecting
  • start the server with: xpra start --idle-timeout=20 and connect a client (you should be able to cancel the timeout)

All of this should work equally well on all platforms, including the html5 client. But full backwards compatibility with older clients is not possible and those will just not be aware of the notification actions.

Last edited 9 months ago by Antoine Martin (previous) (diff)

comment:7 Changed 9 months ago by J. Max Mena

Owner: changed from J. Max Mena to Antoine Martin

Okay I've tested this on every platform I have available to me immediately:

  • I made the mistake of clicking the update button thinking it would only take a few minutes. Boy was I wrong. I won't be making that mistake again.

Everything appears to be working as expected. Is there anything left to do or should I close this?

comment:8 Changed 9 months ago by Antoine Martin

Resolution: fixed
Status: newclosed

comment:9 Changed 9 months ago by Antoine Martin

Also use notifications for reporting failures in:

Minor related fixes:

  • r18264: notification errors should not cause connection failures
  • r18265: use a valid notification id to prevent errors with some backends that require it to be a uint32 (ie: win32)
  • r18266: failures to show a notification should not cause further breakage
Last edited 9 months ago by Antoine Martin (previous) (diff)
Note: See TracTickets for help on using tickets.