Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?


How User Concurrency Works


To support user concurrency on all SBR Carrier servers in a cluster, a simple database table (Sbr_UserConcurrency) in the NDB database stores two fields: the user ID and the current count of user sessions. The Sbr_UserConcurrency table is created automatically when you run the script to create a database.


User concurrency limits (quotas) are enforced during authentication. If the SBR Carrier server is being used as an accounting-only node, user concurrency limits are not enforced.

When an Access-Request is received, the user is authenticated and an ID consisting of an authentication method prefix, a hyphen, and a username is created, such as 0-JANE.

This example script displays all of the user concurrency information in the Sbr_UserConcurrency table.

The ID, 0-JANE, is used to look up the count of open sessions in the table. If this number exceeds the number of sessions allowed, as determined either by native user configuration, LDAP/SQL lookup, or Funk VSA in the Access-Request, the request is rejected. Otherwise, the count is incremented and an Access-Accept is sent.

When an Accounting-Stop is received, the count is decremented. The Class attribute sent in the Access-Accept must be returned in the Accounting-Request so that the user can be matched with the ID in the table for user session counts.

The administrative script decrements the Count field as required. For more details about the script, see

UserConcurrencyID Construction

UserConcurrencyID Construction

The UserConcurrencyID consists of a prefix identifying the authentication method, a hyphen, and a UserName.



The username is the same as the Sbr_UserName field in the Current Sessions Table.

The size of the Sbr_UserName field in the Current Sessions Table and the ID field in the Sbr_UserConcurrency table must be the same. By default, the SQL datatype and size definition is: VARCHAR(32) utf8. It has a customizable character set and size, with a maximum size of 84 characters. The Sbr_UserName field must be large enough to hold all user concurrency IDs.


The username is not guaranteed to be unique among all users; it is only unique when combined with an authentication method.

For details about the Sbr_UserName field and the Current Sessions Table, see the section on Customizing the SSR Database Current Sessions Table in the SBR Carrier Installation Guide.

Authentication Method

Authentication Method

The prefix of the UserConcurrency ID is determined by the authentication method. The authentication method specifies the domain/context in which the username is to be interpreted (a managed database of account names).

There are two authentication methods:

  • Enumerated

  • Proxy

Enumerated Authentication Methods

Enumerated authentication methods are identified by an integer in the range 0–999. In the previous example, 0-JANE, 0 indicates a “native user” enumerated authentication method. Table 103 contains the list of supported methods and prefixes.

Table 103: Enumerated Authentication Methods

Enumerated Prefix

Method Description


Native user


UNIX user


UNIX group


All generic plug-in authentication methods


SIM user


LDAP plug-in authentication method


TLS plug-in authentication method


TTLS plug-in authentication method


PEAP plug-in authentication method


JDBC plug-in authentication method


Oracle plug-in authentication method

Proxy Authentication Methods

Proxy authentication methods are identified by a target-name (for simple proxy) or realm-name (for extended proxy). When defining proxy authentication methods, you must ensure that the target-name or realm-name does not exceed the length of the Sbr_UserName field in the Current Sessions Table and the ID field in the Sbr_UserConcurrency table.

To save space in the NDB database and use minimally sized Sbr_UserConcurrencyId and Id fields, you can name your proxy authentication methods using letters such as A or B.

For proxy authentication methods, the UserConcurrencyID comprises a string-concatenation of the target-name or realm-name enclosed in angle brackets, a hyphen, and a username; for example: <allegra>-JoeUser.


Because they are protected characters used to enclose target and realm names, you cannot use angle bracket or the “greater than/less than” characters < and > as part of the target-name or realm-name.

Authentication Method Consistency

Authentication Method Consistency

You must make sure that all of the authentication methods used by the Session State Register servers in a farm use the same name definition for the same authentication method.

For example, if server #1 defines a JoeUser, native-account for the real-world person Joseph A. User; and server #2 defines a JoeUser, native-account for the real-world person Josephine B. Userette, then both will be assigned a UserConcurrencyID of 0-JoeUser because 0 is the integer value associated with the native-user authentication method. Their user concurrency counts will be corrupt. Similarly, corruption will also occur of server #1 and server #2 both define proxy authentication methods if the same name which don't refer to the same real-world proxy target/realm.

Retrospective Dynamicity

Retrospective Dynamicity

Dynamicity refers to your ability to modify a user's concurrency limit after the user's account has been created. As a result, the user could have some pre-existing sessions after you change the concurrency limit. Retrospectivity refers to what happens to those pre-existing sessions when you change the user's concurrency limit.

In a case where a user has no concurrency limit imposed, to optimize performance, set the UserConcurrencyId field in the Current Sessions Table to NULL. No corresponding record for that user will be created in the Sbr_UserConcurrency table. This minimizes the number of accesses to the database because it is not necessary to update the Sbr_UserConcurrency table when no concurrency limit has been imposed on the user. This represents the no-retrospective-dynamicity model which is the model supported by Session State Register.

Consequences of the No-Retrospective-Dynamicity Model

Consequences of the No-Retrospective-Dynamicity Model

The following examples explain the consequences of the no-retrospective-

dynamicity model.

  • Example #1: JoeUser (a native user) initially has no concurrency limits imposed so his concurrency count is not being tracked in the Current Sessions Table or the Sbr_UserConcurrency table. This enables Joe to start up any number of sessions. In this example, Joe has five existing sessions. Then, the administrator decides to impose a concurrency limit of three on Joe. Joe's previous existing five sessions do not count against his new concurrency limit of three. Instead, this allows Joe to have up to eight simultaneous sessions until some of them start to expire. As a result, the administrator’s intent of limiting sessions to three is not being honored (temporarily).

  • Example #2: JoeUser initially has a concurrency limit of seven imposed so his concurrency count is being tracked in the Current Sessions Table and the Sbr_UserConcurrency table. In this example, Joe has five existing sessions. Then, the administrator decides to re-set Joe’s concurrency limit to three. Joe still has five previous sessions because Session State Register does not try to kill two of Joe’s sessions. However, Session State Register will not allow him to create any new sessions until he drops below the new limit of three. As a result, the administrator’s intent of limiting sessions to three is not being honored (temporarily).

Benefits of the No-Retrospective-Dynamicity Model

Benefits of the No-Retrospective-Dynamicity Model

The benefits of the no-retrospective-dynamicity model are:

  • There is a distinct performance advantage when no concurrency limit is imposed since it requires less accesses to the database, while it causes no adverse effects on performance when concurrency limits are imposed.

  • If an administrator really wants to kill Joe's sessions, he or she can use the admin script.

  • Sessions have a limited lifetime, so they will die off eventually.

  • The no-retrospective-dynamicity model is the most common implementation of limits (quotas), so it is already familiar to administrators.