Scheduling Probe Objects

Via the created and active probe objects, the application requests the API to exchange ISUP messages on its behalf. This is achieved by the API’s asynchronous services, which allow the application to complete other tasks until the API returns a response to the request.

It is the scheduling mechanism which provides these asynchronous services. The mechanism is based on select(), a system call which allows I/O multiplexing, and contains 3 phases:

Pre-select
Select()
Post-select

Pre-select

The pre-select phase is used to set up certain masks and time values according to API requirements.

Masks

The read_mask, write_mask and exception_mask input parameters are bit masks used by the API to shield the IPC descriptions from the application. Do not override the masks by setting them to NULL in you application. They can contain IPC file descriptors managed by the application. Reset (using FD_ZERO) all the select masks that will be used by the application before you enter the pre-select, post-select loop.

The application must initially create these three bit masks in the standard OS manner.

Timeout Value

The application must also provide the API with a timeout value, which is the maximum length of time that the CPU is allowed to be blocked if there is no I/O activity. The API assesses its own requirements and thus, decreases this value to a minimal value, such as 500ms.

selectMask()

The API provides the pre-select method selectMask() to update and modify the masks and timeout value provided by the application.

Using the contents of the read, write and exception masks, selectMask()sets the file descriptor masks to indicate the file descriptors used by the API. The file descriptors managed by the application are left untouched. The returned bit masks are then used by select().

The application must call IsupMgr::selectMask() before each select().

For details about the syntax, parameters, and return values of selectMask() method, see the IsupMgr(3) man page.

Select()

This second phase is the basis of the scheduling mechanism.

select() examines the file descriptors specified by the read, write and execute bit masks. When select() is successful, it modifies and returns these bit masks. The respective masks indicate if a file descriptor is ready for reading or writing, or if there is a pending exception condition.

For details about the syntax, parameters, and return values of select() method, see the select() man page.

Post-select

The post-select phase analyses the results of select() for the API and triggers the necessary processing for the file descriptors (connections) managed by the API. Processing is based on the Work value returned by either IsupMgr::handler() or IsupMgr::doWork().

For details about the syntax, parameters, and return values of the IIsupMgr::handler() and IsupMgr::doWork() methods, see the IsupMgr(3) man page.

Work

Both IsupMgr::handler() and IsupMgr::doWork() return a value known as Work to the application. This value indicates the number of ISUP messages waiting to be received from the network.

handler()

The IsupMgr::handler() determines whether there are primitives to be received from any of the active connections identified in the read bit mask. If there are messages to be received, they are stored in a receive buffer.

It manages all the internal mechanisms and must be called after every OS select(). As the IsupMgr::handler() returns just an estimation of the processing to be done by the API, its CPU overhead is quite low.

It may occur that none of the connections require servicing, such as an internal timeout has been received.

doWork()

After the IsupMgr::handler() call has returned, IsupMgr::doWork() processes the ISUP messages that are waiting to be received. It activates the state-machines and HP OpenCall SS7 ISUP internal mechanism. Finally, it can use the Activity object mechanism to indicate to the application how many primitives are waiting to be received.