|
|
| Line 1: |
Line 1: |
| − | {{ScoutPage|cat=Shared}}
| + | The Scout documentation has been moved to https://eclipsescout.github.io/. |
| − | | + | |
| − | [[Image:ClientNotificationOverview.png|thumb|right|200px|Client Notification Overview]]
| + | |
| − | | + | |
| − | In some circumstances it is necessary to inform the clients about something important. An example could be an incoming call for a specific client or just a request to reload a cache. Such requests from server to client are called client notification.
| + | |
| − | | + | |
| − | Because Scout does its client-server communication over https it is limited to a one-way connection. That means, the server cannot directly call the client, it can only answer him. Therefore the client asks the server about new information after a certain time period. The server delivers all interesting notifications for this client. The <code>ClientNotificationFilter</code> defines for which client a notification is interesting. So we basically have a queue with pairs of <code>ClientNotification</code>s and <code>ClientNotificationFilters</code> on the server-side and each time a client calls for information, the server iterates over this queue. Of course these pairs only have a limited time to live, which is also decided by the implementation of the <code>ClientNotificationFilter</code>.
| + | |
| − | | + | |
| − | The <code>ClientNotificationConsumer</code> will periodically ask the server for new <code>ClientNotification</code>s. There is the possibility to tune the polling interval or the blocking timeout. The polling interval describes after how many milliseconds the <code>ClientNotificationConsumer</code> will do his next polling and the blocking timeout defines how long the call of the <code>ClientNotificationConsumer</code> will wait on the backend to look for new <code>ClientNotification</code>s.
| + | |
| − | | + | |
| − | For better performance and fewer HTTP calls, all client notifications that accumulated during a remote service call on the server are collected and attached to the response of the remote service call as additional payload. That means if the client does frequent server calls the client notification poll interval can be decreased.
| + | |
| − | | + | |
| − | To prevent getting all available <code>ClientNotification</code>s from the server, a <code>ClientNotification</code> can only be provided together with a <code>ClientNotificationFilter</code>. This filter defines how long a <code>ClientNotification</code> is active, whether it is multicast or not and who is interested in this <code>ClientNotification</code>. It is recommended to define your <code>ClientNotificationFilter</code> on the server side, because then you have access to session relevant information like user number or session id. For trivial cases like the comparison of the user number there exists a bunch of default <code>ClientNotificationFilter</code>s.
| + | |
Latest revision as of 05:31, 14 March 2024
The Scout documentation has been moved to https://eclipsescout.github.io/.
