Remote agent by xiaohuicaicai


									         Remote Agent

          Version 0.0

Page 1    Last updated: 28-Oct-11 — 4:36 PM

The database server is capable of serving a large number of subscribers under
strict performance requirements. The design of the network defines that remote
subscribers can be accessed using a satellite. A delay can be generated by:

(1) Computation time and

(2) Communication time.

Usage of satellite channels will contribute at least 0.25 second to every
transaction. A delay of 0.25 second in a telephonic environment is an acceptable
delay. However; this delay will grow significantly due to retransmission requests,
computing delays etc. The remote agent eliminates the communication delay of
the remote subscriber by moving the relevant data on a temporary basis to a
computer adjacent to subscriber. This solution increases the complexity of the
solution, as there is a need to avoid any conflict between the data hosted on the
database server and the data copied to the remote agent.

           Page 2                Last updated: 28-Oct-11 — 4:36 PM
Remote agent

The Remote Agent task is to behave as the database server front end in the
remote site. The database server will be located in the Central Office. However,
the remote support can be given by:

The central office using direct accesses to the database server.
This solution suffers from long response time composed of communication time
and computing time. The advantage of this solution is in its simplicity, as no
special measures are needed to handle far sites.

Using a remote agent in the field as a database server agent.
This solution loosens the connection to the database server and allows remote
users connected via a satellite connection to get telephonic services in a
reasonable grade of service, but creates synchronization problems between the
remote agent and the database server.

The following chat presents the relationship between the database server and
the far users.

           Page 3                Last updated: 28-Oct-11 — 4:36 PM
Migration to the Remote Agent

A subscriber is not committed to a specific Remote Agent. This proposal gives a
flexible solution that enables a subscriber to roam from one Remote Agent to

The following scenario describes the message flow between the Remote Agent
and the database server.

   a. The first attempt to access a user record will generate a fetch fault
       procedure in the Remote Agent.

   b. The remote agent will access the database server retrieving the required

   c. The database server will send a copy of the record to the database server.
       The master copy is kept in the database server and the Remote Agent
       gets a shadow copy.

This procedure is done only in case the subscriber’s record does not exist in the
Remote Agent.

Record Flow

Every record, even a replicated record, has only one “master” copy. The records
base is the database server. This is the main and only copy of the record.

The first request for a record in the remote agent will create a shadow copy of the
record. This shadow record will be an exact copy of the record (or specific parts
of it) that will be transferred from the database server to the agent.

The database server will keep per record the following indicators:

An indication that the record was copied to the agent and the agent identification.

           Page 4                  Last updated: 28-Oct-11 — 4:36 PM
A time stamp indicating the last time that the shadow record was sent to the

A checksum. The checksum will be used to indicate whether the master and the
shadow copies are synchronized. The checksum will be initiated to 0 when a
shadow copy is extracted.

The shadow record has a limited life cycle. The record will have to justify its
existence in the agent. The only reason for keeping a shadow copy in the agent
is real telephonic traffic that requires the information stored in this record. A
shadow record will stored in the agent with the following indications:

Expiration time.
The expiration indicator indicates when the record will loose its right to exist. This
time is an adjustable parameter and is renewed every time that a record
participates in a call. For example, this time is defined to be 10 hours. A shadow
record was created exactly at 08:00 and the expiration time is the day after on
18:00.   In case that there is no traffic, the record will be erased on 18:00.
However, if a record participated in a phone call that started on 10:30, the
Expiration time will be updated to 20:30. The expiration process requires the
agent to verify that the database server updated the indicators indicating that the
shadow record was returned to the database server.

Checksum indicator.
The checksum is a counter that starts with the value 0 when the record is copied
to the agent. Every change to the record will increment the value of this field by

Access flow

Read transaction on the Remote Agent
The agent will try to perform the transaction in the following scenario.

           Page 5                  Last updated: 28-Oct-11 — 4:36 PM
The agent checks the existence of the record in the agent. If it exists, the agent
returns the required value to the requestor and update the expiration time.

In case the record does not exit in the agent, it gets a shadow copy from the
database server, updates its internal data structure with the time expiration
stamp, and the checksum indicator is set to 0 and returns the requested value to
the requestor.

Write transaction in the Remote Agent (or update transaction)
In case there is a need to bring the record from the database server the agent
will perform a read process.

After the read process has terminated successfully or the record already exists in
the agent, the agent will perform the modify action. The modify will perform the
following actions:

Change the record value

Increment the value of the checksum indicator by 1

Acknowledge the transaction to the requestor

Send an update of the transaction to the database server. There is no need to
wait for database server acknowledgement. The acknowledgment is unsolicited
with the subscriber transactions. The record will be sent with the transaction

Audit process

The database server and the agents will periodically perform an audit. This audit
will evaluate the need to synchronize the agent with the database server. In
case the parties are synchronized, the audit will terminate until the check. In
case there is a need to synchronize the agent and the database server, the audit
process will perform the synchronization. The initiation of the audit process will

             Page 6              Last updated: 28-Oct-11 — 4:36 PM
come from the database server. The following actions will be performed when
the agent receives an audit request:

The agent will sum the values of the agent checksums. The value will be sent
back to the database server.

Upon receiving the sum, the database server will calculate the sum of the local
checksums of the records indicated to be in the particular agent.

The database server will compare the results. An equal result indicates that the
entities are synchronized and the audit process can terminate.

The database server will create a list of record keys and checksums (per
subscriber a key + checksum). This list will be sent to the agent

The agent will compare the checksum of every record arrived from the database
server to the checksum stored in the local table. Any unequal value will force an
update of the record in the database server.             During this phase, an
acknowledgement from the database server is required.

Database server transactions

Performing active transactions like “update” on the subscriber record that was
borrowed to the Remote Agent creates a problem. This problem may create an
inconsistent database.

For example, a replenishment request that adds globally free time to all
subscribers or specific subscribers that have a birthday in a certain day may not
be performed on the database server record while the shadow record is stored in
the Remote Agent. This problem can be handled in 3 alternative directions. The
following table presents the alternatives and a short list of advantages and

           Page 7                 Last updated: 28-Oct-11 — 4:36 PM
    #                 Option                              Advantages                Disadvantages

1       Keeping the modification request in               Simple.                      Transactions    are
        a log until the record will expire from                                     unlimited in time.
                                                          No
        the   Remote        Agent       and    the
                                                         synchronization   is           The update can be
        responsibility will be returned to the
                                                         needed                     done in an irrelevant
        database server.
                                                                                    time (too late)

2       Broadcasting the DML request to                   Complicated                  The Remote Agent
        the Remote Agent and performing                                             is    busy   with    non
                                                          No
        the   transaction    in   the    Remote                                     telephonic
                                                         synchronization   is
        Agent.                                                                      transactions
                                                                                        Generate load on
                                                                                    the      communication

3       Recalling   the     record      from   the        Medium                       Some    transaction
        Remote Agent to the database                     complexity                 may be delayed. (Very
        server and performing the DML                                               rare)
                                                          No
        request in the database server. A
                                                         synchronization   is
        forced expiration of the transaction
        will return the shadow record to the
        database server. The validity of the
        record will expire as soon as the
        current telephonic activity ends (if it

              Page 8                           Last updated: 28-Oct-11 — 4:36 PM

To top