Scout/Concepts/Client Notification
| Scout |
| Wiki Home |
| Website |
| Download • Git |
| Community |
| Forums • Blog • Twitter • G+ |
| Bugzilla |
| Bugzilla |
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 ClientNotificationFilter defines for which client a notification is interesting. So we basically have a queue with pairs of ClientNotifications and ClientNotificationFilters 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 ClientNotificationFilter.
The ClientNotificationConsumer will periodically ask the server for new ClientNotifications. There is the possibility to tune the polling interval or the blocking timeout. The polling interval describes after how many milliseconds the ClientNotificationConsumer will do his next polling and the blocking timeout defines how long the call of the ClientNotificationConsumer will wait on the backend to look for new ClientNotifications.
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 ClientNotifications from the server, a ClientNotification can only be provided together with a ClientNotificationFilter. This filter defines how long a ClientNotification is active, whether it is multicast or not and who is interested in this ClientNotification. It is recommended to define your ClientNotificationFilter 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 ClientNotificationFilters.