You can specify hserver options in an options file. This file has different names and locations based on the operating system.

The options file can contain the following lines. Lines that begin with # are considered comments and ignored.

hold Houdini-Master 3600
hold Render -1

When configuring a client machines licensing setup its often required to change the server list to point to the remote license server. The server can either be changed through Hkey ▸ File ▸ Change License Server or through hserver -S <hostname>. Both of these options require intervention from a person which is typically fine for non-studio setusp. The recommended approach for studios looking to automate the installation of Houdini is to use a DNS SRV entry. The advantage with using a DNS SRV entry is that the IT department can update the server listing without needing to push an update to a script or update each client machine manually. Additionally using a DNS SRV integrates nicely with a redundant server setup for your studio.

The order in which an application determines the server listing is as follows:

1. If the application is not hserver then it will query hserver for the listing.

2. If the application is hserver and running as a proper service on Windows. The registry key is checked. The location for the registry key is hklm\software\Side Effects Software\Houdini with variable LicenseServer.

3. If the application is running on Linux/OSX or is not running as a proper service on Windows then the environment variable SESI_LMHOST is checked.

   Windows

   Since hserver runs under a system account the environment variable must be accessible from the user account along with the system account.

4. If the application is running on Linux/OSX or is not running as a proper service on Windows then the .sesi_licenses.pref is used.

   Windows

   Location is %USERPROFILE%/AppData/Local/.sesi_licenses.pref. The location of this file is different for hserver running as a proper service since it runs under a system account. As such its not recommended to adjust this file manually. Let the licensing software adjust this for you.

   Linux

   Location is $HOME/.sesi_licenses.pref.

   Mac

   Location is $HOME/.sesi_licenses.pref.

5. The DNS SRV entry is checked. The application will look for _sesi-lm.

6. mDNS entry is checked. Note sesinetd will set this up if the system allows it. There is no action required for the user.

7. If all above options fail to find a listing then localhost is used. Note this is the case for all new installs of Houdini on a fresh machine.

This configuration allows License Servers (sesinetd) to be chained together. This allows license servers to be broken up based on whatever specification you may have (i.e. license product type). When in this configuration Houdini will try to checkout licenses from the first sesinetd server in the list, then if none are free will try the next server, and so on.

To setup this configuration list a set of license servers separated by a semi-colon instead of specifying a single sesinetd to connect to. The first sesinetd in the list will try to execute the command (i.e. checkout) if that fails for some reason (cannot connect, command failed, etc.) then the next sesinetd is tried, then the next and so on. Make sure to place the connection list in quotes when specify the list using “hserver -S”. For example, hserver -S “sesinetd1;sesinetd2”.

If a comma is used instead of a semi-colon (used for a previous unsupported configuration) the application will log an error and internally use reconfigure itself as if a semi-colon was used. The application will not update the cached server info locations as its entirely possible this choice was intentional for previous Houdini versions.

To use this configuration you need at least an 18.0 Houdini License Server (hserver). The sesinetd and Houdini version do not currently have any requirements for this configuration.

To enable http communication for the HoudiniServer specify the protocol in the connection url (i.e. hserver -S http://licenseserver) or force http communication by adding -C to the command line (enableHttp 1 to the HoudiniServer options file). Starting with Houdini 18.5 HTTP communication is turned on by default for all applications.

Prior to HTTP support Houdini would use a custom format typically called sesi protocol. This protocol was very rigged and was incredibly difficult to inform the client when something went wrong. Whereas with HTTP the entire protocol is well defined and is well supported in third party applications.

The log file is where the server will output information about its health, connection information, and other useful information.

Each log entry is of the form YYYY-MM-DD HH:MM::SS: SYSTEM - MESSAGE.

• HTTP Client are messages coming from curl or messages relating to connection/client systems.

• Sqlite are messages coming from sqlite itself. Sqlite is mostly used for cookie storing or any other persisten storage needs.

• Network Manager is the most common message in the log file. This message typically will come from the server itself. In most cases its used to log information about an incoming connection or response to a request.

• Stats Manager are messages that come from the statistics manager. This is typically messages regarding statistics about the running server (i.e. max process time of a request).

• Error with api response are messages that are a result of an error with an API response.

• Access Token are messages that come from API keys. Typically a message about an invalid API token or unable to update the API token.

• Service are messages that come from the service itself.

• Application are messages that are related to the application. This error message is extremely uncommon.

The log entry Starting release server v18.5.296 at http://127.0.1.1.:1714 displays if the server is a development server or a release server, the server version, the ip address and the port the server is running on. This can come in handy if you need to know the server version you are running on. This also makes it easier to see what version produced what inside a log file that might have multiple server versions in it.

To add API keys for use in hserver add individual api keys with option APIKey or use an API key file with option APIKeyFile. Option APIKeyFile can point to the same file used with HOUDINI_API_KEY_FILE. To generate a new API key go to sidefx.com and select Register a new application. API keys should be treated with the same level of caution and security as email/password credentials.

See hkey for further details on how to setup API keys for hkey and sesictrl.

The license products are ordered based on a hierarchy. The hierarchy is based on the financial cost and features available for that product (i.e. FX > Core > Engine). The system works based on a list of lists. Each sub list represents a license mode (Commercial, Education, Indie, Non Commercial). The order of the lists also tells hserver which are more important and which are less important (the first sublist being the most important). The order of the sublists are [Commercial, Education, Indie, Non Commercial].

[
[Engine, Core, FX],
[Engine EDU, EDU],
[Engine Indie, Indie],
[Apprentice]
]

In this example the list of lists can be transformed into [Engine, Core, FX, Engine EDU, EDU, Engine Indie, Indie, Apprentice] as another way of thinking about the license checkout order. If we take a closer look at the Commercial mode list for hython we have [Engine, Core, FX]. Engine is listed first because its the best license type that suits the application and it also happens to be the cheapest so most customers will want to use up all of these licenses before trying Core or FX. Since FX is the most expensive and isnt exactly meant for hython but can be used to run hython its placed last as most customers will only want to use this as a last resort. Each list within the main list is for each of the license modes and the items within that list are the individual licenses order by their hierarchies based on the application.