Understanding Catalyst Project File Caching Process

Browsium Controller reads the Catalyst project file when the Controller is started, then continues operating using that configuration until the Controller restarts and looks for a new project file, or until the configuration changes if non-default Project Update Activation settings are used. See section 5.6.2 for more details on Project Update Activation.

Catalyst Project File Caching Behavior

Browsium Controller attempts to load the configuration from the Catalyst project file defined in the LoadFromFileName registry value whenever the Controller is started. The location of the file can be local on the client system, a network share, or a web server. The Controller must be able to reach the location where the file is stored, and the user must have at least read permissions on the project file. When the configuration is loaded, a copy of the project file is cached locally in the user’s AppData (HKCU deployment) or ProgramData (HKLM deployment) directory.

If multiple users share the same PC with unique user accounts, or when using a multi-user terminal server, each user will cache a copy of the project file in his/her AppData directory. Those files will be identical if the LoadFromFileName registry value is in HKEY_LOCAL_MACHINE (one entry for all users), or may be different if LoadFromFileName is in HKEY_CURRENT_USER (unique entry per user).

If the original Catalyst project file is not available (the network location is temporarily unreachable or the file has been moved, renamed, or deleted), Browsium Controller will load the previously cached copy of the project file and operate using that configuration until the Controller is restarted and a new project file is available.

This capability makes Catalyst extremely robust and able to remain fully functional regardless of what happens to the project file after it has been loaded and Browsium Client processes are running.

How Catalyst Handles Project File Polling

Some customers deploy Catalyst in a staged rollout to their enterprise user base, which requires updating project files as redirection rules are required. To ensure client systems obtain the updated project file, Browsium Controller includes a Catalyst configuration polling mechanism to check for modified versions of the project file. When Browsium Controller identifies a different Catalyst project file in the target location defined in the LoadFromFileName registry value, by comparing the MD5 hash of the cached file against the target file, the target file is retrieved and cached locally. If the hash matches the current cached file, the target project file is not retrieved.

To ease deployment in large enterprises, Catalyst enables new configurations to be loaded on the fly without restarting the Browsium Controller (which typically requires a reboot or logoff/logon of the client computer). This functionality is governed by Project Update Activation in Project Settings. The default is set to load the new configuration immediately.

To achieve enterprise-level scale, the polling mechanism uses a random interval to discover configuration updates, as noted at the end of this section. It can therefore take up to an hour for Project Update Activation to change the in-memory configuration that Catalyst is actively using even when set to ‘Immediately’.

This setting can be changed to activate the new project at a scheduled time or upon next Browsium Controller restart.

When “At a particular time” is selected, a Project Update Time field is added. This field defaults to 2am but can be changed to any time value. It uses the client’s system clock so that 2am is 2am for every user, regardless of time zone.

The client polling mechanism checks the target project file location at a regular time sequence interval, using a randomly generated seed time point. The randomly generated seed value helps ensure large scale deployments do not simultaneously try to retrieve the project file, avoiding a denial of service or network traffic storm issues.

Browsium Controller simply compares the computed MD5 hash of two files and uses the target file if the two signatures are different. No effort is made to determine which file is newer (either by time/date stamp or content analysis) so administrators must ensure updates to the target file location are done carefully to avoid clients regressing to an older project file configuration by mistake.