Interest Management

Hadean Connect is able to filter data that is sent to a connected client both in terms of what data is sent but also how often it is sent an a mechanism referred to as Interest Management.
The default Connect Interest Management policy allows a client to register one or more focuses of interest around which the Connect's interest management policy will be able to filter out data that is outside of the Clients region of interest. It is possible to also define a list of always visible entities for each connected client that can be controlled through a separate set of interest management rings
​
Spatial Policy
The interest management policy is defined in terms of a series of concentric rings around a client's points of focus. Each ring can have different update frequencies defined, with any updates for entities outside the largest defined ring never being sent. Additionally, it is possible to apply a gradient function so that changes in update frequency are applied gradually when crossing from one ring to another.
Configure
Interest management policy is defined by populating [[generic_ring]] tables in the configuration file muxer_config.toml. The file uses the toml configuration format and can be  found in muxer-sdk/autoscaler/data/muxer/muxer_config.toml within the extracted folder structure from the Connect archive.
There is no limit to the number of rings that can be defined. In the example below we set a policy with two rings, the small inner ring has a radius of 40 units around the point of focus, updates are sent every 100ms and a constant gradient is set, this means that updates will be sent at 100ms intervals irrespective of where in the ring an entity is. A second ring is defined extending to a radius of 80 units with an update frequency of 500ms. In the second ring a linear gradient is used. This means that at the outer edge of the ring entitles will be updated every 500ms, but at the inner edge they will use the update frequency of the inner ring, in  this case 100ms with a linear increase in between, so an entity 60 units away from the focus point would issue updates every 300ms
muxer_config.toml
[[generic_ring]]
radius    = 40.0        # Distance from focus point in units used in simulation
period_ms = 100         # Minimum time between updates
gradient  = "constant"  # How update rate should vary within ring
​
[[generic_ring]]
radius    = 80.0 
period_ms = 500
gradient  = "linear"
Always Visible Policy 
Whilst filtering data based on the distance of of an entity is an excellent way of controlling bandwidth, it is often necessary for a Client to have persistent visibility of other entities. Connect provides a means to define a list of entitles for each connected client that will always be visible. Like spatial based interest management it is possible to define rings around the clients point of focus that define an update frequency for entities flagged as always visible that are within that ring. This is done in the same file
Even if you are not providing a list of additional always visible entities for a connected client, the entity controlled by the client will still be considered to be in this list. Therefore the smallest always_on_ring will define the update rate for the entity that client is controlling.
muxer_config.toml
# The smallest ring sets update rate for player controlled character
[[always_on_ring]] 
radius = 1.0 
period_ms = 0 
gradient = "constant"
​
[[always_on_ring]] 
radius = 10000.0 
period_ms = 500 
gradient = "linear" # linear or constant
​
[[always_on_ring]] 
radius = 50000.0 
period_ms = 1000 
gradient = "linear" # linear or constant 
Example Use Cases: To ensure that aircraft in a simulation have visibility of all other aircraft, but to filter out ground traffic Implement a friends list for a metaverse style simulation to ensure that friends were always able to see each other even if they were outside of the usual viewing range.
Defining Always Visible Entities for a Client
 In order to obtain friends and party information for a particular player entity, Connect will first get the service token from a specified REST API endpoint and then query another endpoints for friends list and party information, using the token for authorisation. Configure The credentials & endpoints for obtaining friends and party information are specified via the muxer_config.toml in the [friendlist_api] section of the configuration file . An example configuration is listed below
muxer_config.toml
[friendlist_api]
request_token_url = "https://customer-side/token"
request_token_user = "request_token_credentials_user" 
request_token_secret = "request_token_credentials_secret"
​
friends_url = "https://customer-side/friends/" 
parties_url = "https://customer-side/party/" 
request_token_url - url , used by Connect to obtain the service token request_token_user / 
request_token_secret - credentials , used by Connect to obtain the service token 
friends_url - url , used by Connect to obtain the friends list 
parties_url - url , used by Connect to obtain the party information 
If [friendlist_api] entry is not present in the configuration file, Connect will not attempt to perform any REST API logic
​
​
Muxer Server Plugin
Next - Get Started
Building with CMake
Last modified 1mo ago
Copy link
Outline
Spatial Policy
Always Visible Policy
Spatial Policy

Configure

Always Visible Policy

Defining Always Visible Entities for a Client

​
