|
|
United States-English | |
|
|
 |
|
hp OpenCall SS7 platform Application Developer's Guide: For Release 3.1 on Linux > Chapter 7 Using the TCAP Application Message
Dispatcher
Some Approaches to Dispatching Design |
|
|
The rest of this chapter gives some examples of how the TCAP Application Message Dispatcher feature might be used and how the various components might react in certain circumstances. It is the customer’s responsibility to code the functions to obtain the desired behavior. These examples are intended to give you some ideas, they are not to be taken as recommendations for design. It is possible to employ a different technique for each SSN. For example, messages destined to one SSN are distributed based on partitioning, while messages destined to another SSN are distributed on a round robin basis. In this case, the customer-supplied library contains a different dispatching table for each SSN. The examples are:
The idea behind partitioning is to base the dispatching on some value inside the message. For example, one range of called numbers is passed to one application instance, and another range is passed to another application instance. In this case, you code the function TCAProuter_incoming_message() so that it looks for the value within the message, and based on this value, returns the appropriate application and instance identifiers. For example, several applications are running, each of which handles requests for a range of called numbers. Each application has read/write access only to the section of the database concerning its own range of numbers. This arrangement increases performance by having each application keep a section of the database or a cache of the database in its memory. As a consequence, if any given application is not running, the messages with values in the range for that application are rejected. When an application starts up, it reads its section of database into memory and connects to the stack. It identifies itself to the stack using its application ID and instance ID in the call to TCX_open(). TCAProuter_init() sets up a dispatching table that maps called number ranges to application and instance identifiers. TCAProuter_application_activate() and TCAProuter_application_deactivate() update the in-memory table to keep track of which applications are active. TCAProuter_incoming_message() decodes the message to get the numeric value. Using this number, it looks in the table to obtain the proper application ID and instance ID, and returns them to the stack. Otherwise, -1 is returned to indicate that the message could not be dispatched to any application. The idea behind load balancing is to send messages to the least busy application instance. When an application starts up, it identifies itself to the stack using its application ID and instance ID in the call to TCX_open(). TCAProuter_init() initializes the library’s internal dispatching table. TCAProuter_application_activate() updates the library’s internal dispatching table to allow dispatching to that application. TCAProuter_application_deactivate() updates the library’s internal dispatching table to disallow dispatching to that application. TCAProuter_incoming_message() routes the message to the application with the lowest value for the number of transactions. This example uses the number of transactions as an indicator of the load, but this is not necessarily a good measure of the real traffic load. The real traffic load depends more on the number of messages in a transaction rather than on the number of transactions. If TCAP Application Message Dispatcher is not enabled, the default method of distributing messages to applications connected at the TCAP interface is round robin. This functionality is provided by the stack. If TCAP Application Message Dispatcher is enabled, the stack passes all incoming TC-BEGIN and TC-UNI (or the ANSI equivalents) to the customer-supplied library function TCAProuter_incoming_message() for dispatching. If it is desired to have applications responding to one SSN to be distributed based on something in the message, and those applications responding to a different SSN distributed on a round robin basis, the customer-supplied library must also provide the round robin mechanism. The stack and the shared library do not share dispatching responsibility. If TCAP Application Message Dispatcher is enabled, the shared library is responsible for dispatching. If TCAP Application Message Dispatcher is not enabled, the stack is responsible for dispatching. When an application starts up, it identifies itself to the stack using its application ID and instance ID in the call to TCX_open(). Each application ID and instance ID is indexed by a number. A counter is maintained in the library to keep track of which one took the last message. TCAProuter_incoming_message() increments the counter and wraps it around from the last index to the first (when necessary). It does this until the counter indexes an active application. TCAProuter_application_activate() updates the library’s internal dispatching table to allow dispatching to this application instance. TCAProuter_application_deactivate() updates the library’s internal dispatching table to disallow dispatching to this application instance. The idea behind uneven distribution is that some application instances have more capacity than others. For example, it might be desirable to send twice as many messages to one application instance than to another. When an application starts up, it identifies itself to the stack, using its application ID and instance ID in the call to TCX_open(). The library’s internal dispatching table contains an integer field for each application instance to indicate the desired percentage of transactions to be routed to that instance. It may also contain an integer field for each application instance indicating the current percentages given the number of instances that are currently connected and active. TCAProuter_init() initializes the library’s internal dispatching table loading the desired percentage values. TCAProuter_application_activate() updates the library’s internal dispatching table to allow dispatching to that application instance, and to adjust the current percentages to accommodate the number of application instances currently alive. TCAProuter_application_deactivate() updates the library’s internal dispatching table to disallow dispatching to that application instance, and to adjust the current percentages. TCAProuter_incoming_message() looks in the table of user transactions passed by parameter, and at the current percentages for each application instance, to determine which instance gets the message. The actual weighting used depends on the customer needs. The idea behind dispatching based on the INAP service key is that different applications handle different INAP services, so incoming messages are distributed by INAP key. When an application starts up, it identifies itself to the stack using its application ID and instance ID in the call to TCX_open(). The library’s internal dispatching table maps the INAP service key to different application and instance IDs. TCAProuter_application_activate() updates the library’s internal dispatching table to allow dispatching to this application instance. TCAProuter_application_deactivate() updates the library’s internal dispatching table to disallow dispatching to this application instance. TCAProuter_incoming_message() decodes the message up to the Service Key and then maps the Service Key value to the appropriate application instance through the dispatching table. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||
 Printable version |
|
|
|
|
|
|||||||||||||||
|
|||||||||||||||
