Update server-client-communication.adoc

- Fix heading levels
- Other minor edits

Author: jouni

articles/flow/advanced/server-client-communication.adoc

@@ -7,12 +7,14 @@ 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.
+Server to client communications contain the synchronization tokens 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.
+
+== Synchronization Tokens
 
 The `syncId` token marks the state of the server and is returned as received by the client. Whereas, the `clientId` token is incremented for each message sent by the client, with the server incrementing to match the next id in the response. Both `syncId` and `clientId` are integers.
 
 
-==== `syncId`
+=== syncId
 
 The `syncId` holds the latest communication state identifier given by the server. It's generated as a strictly increasing id for each response to every request from the client.
 
@@ -23,7 +25,7 @@ The initial value when no response has been received from the server is `UNDEFIN
 The `syncId` is always incremented by 1 after a new UIDL response is generated. The client then handles the received messages according to the `syncId` and the latest handled `syncId`, so that changes are handled in the correct order.
 
 
-==== `clientId`
+=== clientId
 
 The `clientId` holds the latest communication state identifier given by the client. The client token is incremented on the client after sending the message. The server increments the value in the response to match the next expected `clientId` (i.e., client updated after message sent).
 
@@ -32,39 +34,39 @@ 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
+== 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 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 which were meant for a different session or UI.
-- *Firewall or Virtual Private Network (VPN) interference:* Deep packet inspection can block certain packets.
+- *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 delays.
 
 Other potential causes include:
 
-- *Faulty router hardware:* This could be due to routers using outdated firmware versions.
+- *Faulty router hardware*: This could be due to routers using 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, possibly due to server performance degradation.
+- *Server-side issues*: Request-handling hiccups may lead to inconsistencies, possibly due to server performance degradation.
 
 
-== Re-Synchronization Initiation & Mechanism
+=== Re-Synchronization Initiation & Mechanism
 
 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. Below is the process followed to re-synchronize:
 
-*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 detached listeners of UI components and re-attaches all components to the state tree.
 - The server then sends a response that includes the current UI state needed to rebuild 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.