Wide-Area Forwarding: Runtime Conditions

Intra-Realm Scope

Wide-area forwarding requires that all servers and services operate within a single realm, even though they are located at different geographic locations. The example in the diagram satisfies this condition by configuring the core servers in Rio as primary servers, and the core servers in London and Tokyo as satellites of the Rio primaries. Configure these relationships in the FTL server configuration file.

Core Server Clusters

The local realm services direct the client to the local persistence cluster (purple arrows).

This mechanism places two conditions on the topology of the FTL servers and persistence services.

If two persistence services belong to the same persistence cluster, then they must connect to realm services within the same cluster of core servers. Conversely, if two persistence services belong to two separate persistence clusters, then they must connect to realm services in different clusters of core servers.

The example in the diagram satisfies these conditions. For example, the persistence services (triplet of three pink services) in London all connect to realm services in FTL servers L1, L2, or L3. The diagram illustrates this connection as the arrow into L2, implying similar arrows from all three London persistence services to all three London FTL servers.

In contrast, a persistence service in London must not connect to FTL servers in Rio or Tokyo. The dashed arrow into T1 would contradict this condition.

Configure these relationships in the FTL server configuration file.

Durable Identity and Core Servers

As mentioned previously, the local realm services direct the client to the local persistence cluster (purple arrows). This mechanism yields two corollaries and a condition.

If two clients connect to different core servers within the same cluster, and each subscribes to durable D, then they access the same durable.

In contrast, if two clients connect to distinct clusters, and each subscribes to durable D, then they access different durables (which could have different message content).

To maintain consistent access to a durable, a client must always connect (and reconnect) to the same cluster of core servers.