Table Of Contents
Client Registration and Deregistration
Reverting to the Last Sync Time
Retrieval of Version Information
WANDEST Server
The WANDEST server uses CORBA for synchronization and data extraction from the CWM stratacom database to the WANDEST server.
Note
Only tables in the stratacom database are supported.
The WANDEST server provides the following services:
•
•
•
•
External Functions
This section describes the server functions. The interface specifications to the CORBA objects are described in "Server IDL Interface Definition."
A typical interaction between a WANDEST server and client is shown in Figure 2-1.
Figure 2-1 Full Upload and Incremental Updates Client and Server Interactions
Client Registration and Deregistration
A client is uniquely identified by its host name and application name. When a client registers to the WANDEST service, WANDEST server stores that client registration in its database. At that time, the server begins tracking database changes. This registration remains in the database even if the client terminates and disconnects from the service.
When a client invokes an incremental update upon restarting, that client must not deregister. After terminating, a deregistering client must invoke a full update when reconnecting to the server. Table 2-1 describes client states and actions.
Full Upload
WANDEST provides a full upload service of all data in the CWM stratacom database. A client must request a full upload when it first registers to WANDEST and whenever the client reregisters after a deregistration.
The files are transferred from server to client using the FTP put command. Uploaded file names are returned in the output parameter passed into the CORBA request.
Uploads of two different sets of tables can be processed concurrently, so multiple threads in the client can simultaneously request an upload for different tables. When more than one table exists in the request, the server processes the requests concurrently, using a pool of threads. When any operation in a request of multiple tables fails, the whole request fails, and the sync time does not advance. When a request contains just one table, a successful operation advances the sync time. A failed operation does not advance the sync time.
The starting time of the upload process is marked as the last sync time used by the Incremental Update interface to determine the updates that need to be sent to the client.
Incremental Updates
WANDEST provides an incremental update service that consists of insertions, modifications, and deletions that occurred since
•
or
•
The files are transferred from server to client using the FTP put command. Uploaded file names are returned in the output parameter passed into the CORBA request.
Updates of different sets of tables can be processed concurrently; therefore, multiple threads in the client can simultaneously request an update for different tables. When more than one table exists in the request, the server processes each table concurrently in separate threads.
Tracking CWM Changes
The server records all changes to the CWM database in files called tracking tables. WANDEST supports the creation of one tracking table per CWM table. When a row in the CWM table is inserted, updated or deleted, the tracking table is updated to reflect the change.
Reverting to the Last Sync Time
The WANDEST server can revert to the previous last sync time, thereby resending the previously requested data and any new changes. Reverting allows the client to request that the server resend the data from the previous getUpdates command to the current time.
CWM Schema Verification
The client sends the current CWM master schema for the tables noted in the Control file to the server. The server then checks the tables and columns from the client Control file against the CWM database schema to examine the following conditions:
•
•
•
•
When an error occurs, the server generates an exception, and the WANDEST client logs the error into the log file. Unless all of the information is valid, the WANDEST client does not start the full upload or incremental update.
Note
Retrieval of Version Information
The WANDEST server sends the versions of CWM, the WANDEST server, and IDL when queried.
Exception Handling
Exceptions are reported using CORBA exceptions as defined in the IDL file. For a complete listing of server exceptions, see "Server Exceptions" section.
Objects Life Cycle
This section defines the objects that are relevant to the IDL interface.
The WANDEST server CORBA interface defines two objects: WanDest::Admin and WanDest::Server for providing its services. The WanDest::Admin class has exactly one instance created and activated by the server. The WanDest::Server class has one instance per client and is persistent. This instance is created and deleted by the client registration and deregistration operations. A third object, WanDest::Maint, is provided for maintenance services.
Concurrency
Both the getFullUpload() and getUpdates() methods take the Request structure as their argument, where clients specify lists of tables in the Control file. For a multi-threaded client, the server supports multiple requests for different sets of tables. The server processes a request by unloading and transferring several tables concurrently in a pool of threads via FTP.
The server sends an exception when it receives more than one request from the same client for the same table.
Constraint Checking
The following constraints are checked:
•
•
Clean-up of Tracking Tables
For the incremental updates service, the server uses tracking tables that increase and decrease as rows are inserted and deleted, respectively. The server must perform periodic cleanups to control the size of these tracking tables. These cleanups are managed by the CLEANUP_PERIOD parameter in the server Configuration file. For each table, the server compares the oldest previous last sync time with the previous last sync time and removes the files with the older time stamp.
Sync Expiration
The server checks if the last sync time of any client files exceeds a maximum allowable sync time period. This sync check is managed by the SYNC_EXPIRATION_TIME parameter in the server Configuration file. When the server detects that a client has a sync expiration, the server marks the state as expired for that client. The next time that client requests an incremental update, the server sends an exception indicating that a full upload is required.
Logging
The WANDEST server logs all requests made through its interfaces and any exceptions that may occur. All WANDEST errors and exceptions are listed, along with the error levels, in "Exceptions and Errors."
Run Time Issues
This section describes the WANDEST server run time issues.
Server Startup
The WANDEST server process is started as part of the CWM processes managed by the watchdog process. Example 2-1 shows the WANDEST server process starting up:
Example 2-1 Server start up
Cisco WANDEST Server Vs 2.4Interfaces:WanDest_AdminWanDest_ServerWanDest_Maint[WanDest: New Connection (nmult61.cisco.com,IT_daemon,*,root,pid=18532,optimised) ][WanDest: Server "WanDest" is now available to the network ]For more information on CWM startup, refer to the Cisco WAN Manager User Guide.
Server Termination
The WANDEST server termination process is started by the CWM watchdog process immediately upon WANDEST termination.
Client Termination
The server is not aware of the clients state. The client can be started, stopped, or run continuously.
The Server Configuration File
The WANDEST server Configuration file is created upon installation and populated with default values. This file is installed in /usr/users/wandest/server_files/wdserver.cf. Table 2-2 defines all of the server Configuration file parameters and their default values.
Table 2-2 Server Configuration File Parameters
ROOT_DIR
/usr/users/wandest
Home directory where WANDEST-related files are installed. The destination path for both the WANDEST server and client is fixed to /usr/users/wandest. This path cannot be changed during or after installation.
OUT_DIR
/usr/users/wandest/data
Directory where WANDEST places uploaded data files.
WANDEST_DB_NAME
wandest
WANDEST database name.
DB_NAME
stratacom
CWM database name. Only all tables in the stratacom database are supported.
SYNC_EXPIRATION_TIME
60000
Maximum interval (seconds) between the last sync-up (a full upload or an incremental update) and an incremental update.
MAX_THREADS
50
Total number of threads the WANDEST server can spawn.
MAX_THREADS_PER_CLIENT
5
The total number of threads, per client request, the WANDEST server can spawn.
DISK_SPACE_CRITICAL
1
Critically low disk space threshold in megabytes.
DISK_SPACE_WARNING
2
Low disk space threshold in megabytes.
CLEANUP_PERIOD
600
Interval between tracking table cleanups in seconds.
STANDBY_LAGTIME
600
Number (seconds) that the markSyncTime method subtracts from the current sync time.
ROW_QUERY_TABLES
|asi_port|ausm_port|frp|line|
Tables that can be queried using the WDServer::waitForRowInsertion() method. The string must contain the concatenated table names, separated by the "|" character.
STORED_PROCS
|GetEndParam|
Stored procedure that can be invoked using the WDServer::invokeStoredProc(). The string must contain a concatenated stored procedure name, separated by the "|" character.
LOG_LEVEL
2
Log level at which the messages are written to the log file. See "Exceptions and Errors."
