Push notification workflow details

The following image shows architectural information about the components in the push notification process.

The following sequence diagram shows how the components interact in the push notification process. The numbers in the diagram refer to the steps below that describe the push notification process.

The following steps describe how the client, web server, push redirector, and push server interact during the push notification process:

1. The push redirector establishes a connection with the push server:
   • On startup, the push redirector running on NexJ Server sends an HTTP request and establishes a standard HTTP connection to the push server running on each node of the application server as part of the NexJ application. The push redirector sends the request using the credentials of a special push user. This user is authenticated using the authentication method configured for the NexJ application. The push server authorizes the push redirector by ensuring that the push user has the appropriate push privilege.
   • To hold the connection open indefinitely, the response to the request is not committed by the push server.
   • If a connection failure or timeout occurs, the connection is reestablished. If the push redirector is unable to connect, a connection attempt is repeated every 10 seconds.

   You can configure several push redirectors to connect to the same push server. The push server load balances client requests across the push redirectors (see step 5). If a connectivity disruption occurs, the push redirector reconnects to the push server and sends a count of currently connected clients to the push server. The push server’s load balancing algorithm uses the count to load balance client requests.

2. A client (browser) sends a request to the push server to request and register for push notifications. For example, a browser sends a request through an HTTP server, such as Microsoft Internet Information Services (IIS) or Apache HTTP Server. The client request is authenticated using the authentication method configured for the NexJ application.

   If a connection between a push redirector and a push server does not yet exist, the push server waits for up to 60 seconds for the connection to be established. This is to ensure that, if the push redirector and the push server are started at the same time, the redirector has enough time to establish an initial connection to the push server.

   Note: If there is no connection to the push redirector, the push server responds with an HTTP 500 error code.

   The push server generates a unique client ID and sends it along with the object ID (OID) of the authenticated user to the push redirector on the open connection established earlier. This ensures that only client requests from authenticated users are accepted by the push redirector after redirection by the push server.

3. After receiving the unique client ID and the OID of an authenticated user, the push redirector stores the mapping of the IDs and waits for a maximum of 30 seconds to receive a client request with the same client ID (see step 4). If the request is not received, the client ID and OID mappings are removed from memory. If the client request is received after the redirection timeout period, the request is rejected with an HTTP 403 error (see step 5).
4. The push server responds to the original client request with a redirect, passing the unique client ID as a parameter in the redirect URL:
   Note: The redirect functionality in this case is not a standard HTTP redirect. Instead, the push server simply writes the push redirector URL in the response and the client must follow the redirect URL manually. This is done to avoid cross-domain redirection restrictions. For more information, see Raw data.
   • If multiple push redirectors are available, the push server redirects the client to the push redirector with the lowest number of connected clients. Client count updates are received from the push redirector periodically (see step 8).
   • If the connection to any of the push redirectors is disrupted, the push server takes the push redirector out of rotation and stops redirecting clients to it. The push redirector can establish the connection at a later time if it recovers from the problem that caused the disconnection.
5. The client follows the redirect to the push redirector with the unique client ID in a URL parameter:
   • Upon receiving the request, the push redirector tries to match the client ID from the request to one of the client IDs sent to it previously by the push server. If successful, the push redirector sends a client count update to the push server (see step 8) and establishes a Comet connection with the client. The response is not committed.
     Note: Microsoft Internet Explorer has a limitation where the browser begins flushing the server output of an uncommitted response only after the first 256 bytes have been received. To avoid this limitation, the push redirector writes 256 bytes of dummy data to the response output stream for every new Comet connection that is established with a client. Client-side code should ignore the first 256 bytes of data received from the server for each new connection established with the push redirector. The client can also use the dummy data to detect whether notifications are not reaching it and attempt to take corrective actions, such as switching from data streaming to long polling mode.
   • If the client request arrives at the push redirector before the unique client ID (see step 3), the redirector caches the client request and waits for a maximum of 30 seconds for a matching client ID to arrive from the push server. If the client ID is not received within this time, an HTTP 403 error is returned to the client.
   • If the connection between the push redirector and the push server is disrupted:
     • The push redirector disconnects clients currently connected in 50 ms intervals. This ensures that multiple clients do not attempt to reconnect at the same time.
     • The clients register for push notifications with the push server again.
     • The push server detects the connection disruption and fails clients over to another push redirector.
     • If the push redirector re-establishes its connection with the push server, the push redirector stops disconnecting clients. Connected clients continue to function normally.
6. The push server sends a notification for a specific notification key, when new data in the NexJ application is available to communicate to clients:
   Note: The notification key is required.
   • The notification can be targeted to a specific user OID. If no OID is specified, the notification is broadcast to all clients.
   • If multiple push redirectors are available, the notification is broadcast to all push redirectors because it is not known which push redirector holds the client connection.
7. When the notification is received by the push redirector, it selects clients to push the notification to:
   • If the OID is specified, the push redirector identifies client IDs that are mapped to the OID. If the OID is not specified, all registered clients are selected.
   • Clients that are selected must also be registered to receive notifications for either the specific notification key or for any key.
   • Once all the matching clients are identified, the push redirector sends the notification to clients using the open Comet connection.
8. When a client connects to or disconnects from the push redirector, the push redirector updates the push server with the count of connected clients. To avoid extraneous communication between the redirector and server, the update is not sent on every client connect or disconnect. An update is sent when the actual number of connected clients differs by more than 10 from the number that was last reported to the push server. This optimization can cause load balancing between the push redirectors to be off by up to 10 clients.