Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Navigation  Back up to About Overview 
[+] Expand All
[-] Collapse All

Customizing the CST

A key benefit of Session State Register is that you can modify the CST to meet a site’s requirements by adding or modifying session fields. However, if you make too many modifications, or make them incorrectly, problems can occur. Review the following notes before making any modifications, and test your changes as you go.

In general, try to use as many defaults as possible, and add only what is required.

Propagating a Changed CurrentSessions.sql File

Because you are working in a cluster environment where multiple machines use the same data, making changes to the CST table is not a trivial task. Each time you change the configuration file, it must be distributed to all management nodes. Then you must eliminate the existing database (with the command) and create a new database. (As hadm, execute the command on all management nodes.)

Performance and Capacity Considerations

Each field that you add to the CST increases the size of every session record stored in the CST. Larger tables increases the amount of memory required by the database. As a result, adding fields to the CST limits the number of simultaneously active sessions that can be stored in the CST, given fixed memory and disk space. Adding fields to the CST slows wire communications and internal processing time.

The Steel-Belted Radius Carrier SSR implementation limits the maximum supported size of a CST field to 4096 bytes. This limit matches the maximum size of a RADIUS packet as defined in RFC 2865. RFC 2865 also limits each packet’s individual RADIUS attributes to a maximum of 253 bytes.

In practice, RADIUS attributes and packets are usually much smaller than 4096 bytes. The entire cluster runs more efficiently when fields are tuned to the size of a site’s RADIUS attributes and corresponding RadAttr fields.

Additional Keys

The default CurrentSessions.sql contains the primary key for the CST and other keys (indexes) required for Steel-Belted Radius Carrier operation. You can comment unused keys out, but we recommend that you do not delete any of these in case they need to be restored. You can additional keys on any fields to support faster lookups for site-specific tools or third-party products. Each additional key adds overhead every time a row (session) is added to or removed from the CST.

Stored Procedures

SSR includes basic stored procedures defined in the StoredRoutines.sql file. You cannot modify or delete these stored procedures, but you can define new stored procedures to perform special handling of RadAttr fields for tools you may use or create. Creation of custom stored procedures requires advanced knowledge of SQL.

Remember that SQL queries tend to run more slowly, and to require more resources, than queries and scripts (such as the admin scripts) that use NDBAPI.

Customized CST Applications

You can write custom SQL-based tools to query the SSR database. You can base these on the SSR database CLI (just as is), or the tools can talk directly to a SSR management server mysqld daemon. You can also define new stored procedures in StoredRoutines.sql and may create new NDBAPI applications.

Modified: 2017-10-26