From 58d07516cc91e2acf12e2d4314e9257faf28390c Mon Sep 17 00:00:00 2001 From: russelljtdyer <6652767+russelljtdyer@users.noreply.github.com> Date: Mon, 23 Dec 2024 08:31:41 +0100 Subject: [PATCH] First set of edits. --- .../advanced/server-client-communication.adoc | 28 ++++++++----------- 1 file changed, 12 insertions(+), 16 deletions(-) diff --git a/articles/flow/advanced/server-client-communication.adoc b/articles/flow/advanced/server-client-communication.adoc index 4ded31b0d8..08200e6b0e 100644 --- a/articles/flow/advanced/server-client-communication.adoc +++ b/articles/flow/advanced/server-client-communication.adoc @@ -4,6 +4,7 @@ description: Technical details of how server to client communications work. order: 800 --- + = Sync Server & Client UI States Server to client communications contain the synchronization tokens -- `syncId` (server-to-client) and `clientId` (client-to-server) -- for communicating and UI state tracking. This tracking is meant for ordering messages. It's also used to verify that both sides are in the same known state. @@ -30,47 +31,42 @@ On the client, pending messages are removed from the queue as handled when `clie On the server, in cases where the id is the previous one with the same request payload, the server re-sends the latest response since the client probably didn't receive the message. If the client-sent id doesn't match the server-expected id, a re-synchronization is initiated. -= UI State Re-Synchronization -Re-synchronization occurs when the client detects that its state is no longer in sync with the server. This can happen due to issues such as unexpected network interruptions or inconsistencies between the client-side UI and server-side state caused by misconfigured reverse proxies or session replication setups. += UI State Re-Synchronization -== Reasons for Re-Synchronization +Re-synchronization occurs when the client detects that its state is no longer in sync with the server. This can happen due to issues such as unexpected network interruptions, or inconsistencies between the client-side UI and server-side state caused by misconfigured reverse proxies or session replication setups. Several factors can lead to message loss or unexpected message identifiers: -- *Incorrect load balancer or reverse proxy configuration*: Using setups without sticky sessions may result in receiving messages from the server meant for a different session or UI. +- *Incorrect load balancer or reverse proxy configuration*: Using setups without sticky sessions may result in receiving messages from the server which were meant for a different session or UI. - *Firewall or Virtual Private Network (VPN) interference*: Deep packet inspection can block certain packets. -These factors might also generate a delay in arrival of the messages. - -Virus scanners are particularly problematic and may cause issues when `WebSocket_XHR` is used. -Increasing the `maxMessageSuspendTimeout` parameter value could help mitigate message arrival delay issues. +These factors might also generate a delay in arrival of the messages. Virus scanners are particularly problematic and may cause issues when `WebSocket_XHR` is used. Increasing the `maxMessageSuspendTimeout` parameter value could help mitigate message arrival delay issues. Other potential causes include: - *Faulty router hardware*: Routers running outdated firmware versions. - *Unstable Wi-Fi or cellular connections*: Fluctuating network conditions can disrupt communication. -- *Server-side issues*: request-handling hiccups may lead to inconsistencies, e.g. due to server performance degradation. +- *Server-side issues*: Request-handling hiccups may lead to inconsistencies, possibly due to server performance degradation. + -== Re-Synchronization Initiation and Mechanism +== Re-Synchronization Initiation & Mechanism -Re-synchronization is initiated by the client when it cannot find a message with the expected `syncId` among the pending messages from the server within a given timeout (default: 5 seconds, configurable using the `maxMessageSuspendTimeout` parameter). +Re-synchronization is initiated by the client when it can't find a message with the expected `syncId` among the pending messages from the server within a given timeout. The default is 5 seconds, which is configurable using the `maxMessageSuspendTimeout` parameter. -. Client Initiation: +*Client Initiation:* - The client clears the queue of pending messages from the server. - It terminates the current request and sends a re-synchronization request to the server. -. Server Handling: +*Server Handling:* - Upon receiving the re-synchronization request, the server invokes the detach listeners of UI components and re-attaches all components to the state tree. - The server then sends a response that fully includes the current UI state needed for a rebuild of the client-side state tree. -. Client Update: +*Client Update:* - The client receives the updated UI state from the server. - It clears all old pending messages, updates the last known `syncId` to the newly received value, and rebuilds the DOM tree from scratch based on the server's current state. -*Benefits* - This process ensures UI consistency, even in the presence of errors or unexpected behaviors. The application remains robust against transient network issues or client-side interruptions. Additionally, the user experience is preserved without requiring a full page reload, as Vaadin rebuilds the UI without reloading the entire bundle from the server.