warning notifications

[totaam]

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:

• electron notifications (Windows, Linux, macOS)
• electron-notification-state links to the apis needed to honour "do not disturb" mode on win32 and macos

See also: #1492, #1305

[totaam]

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 User should be notified when a file is uploaded from the server #1375 already provides a dialog..

[totaam]

• 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?

[totaam]

• related network improvements: better TCP_NODELAY handling: only use it when it is useful #619#comment:12
• heuristics improved in r18138
• lots of bandwidth detection improvements: see catch limited bandwidth issues sooner #999#comment:44
• discovered a bottleneck with opengl: present_fbo vsync delays sending paint acks #1754

[totaam]

• mostly done for bandwidth issues in r18194 (detect bad connection and warn the user #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 settings changed on the server should be forwarded to the client #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.
• done for idle-timeout (Handler for user timeout #803) in r18200
• see also notification enhancements: icons, etc #1492#comment:9 (win32 clients will now show notifications actions using the gtk notifier).

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 re-implement bandwidth constraint option #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.

[totaam]

2018-02-01 23:52:22: maxmylyn commented

---

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

• Fedora 26 (r18247)

• Win8.1 (r18200 beta)

• MacOSX (r18200 beta)

• 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?

[totaam]

Also use notifications for reporting failures in:

• r18250: webcam
• r18252: audio
• r18253: opengl
• r18259: desktop scaling

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