|
|
Communication between Central and Distributed Mediation Servers is required for information exchange which includes client requests and responses. The communication between the Central Server and Distributed Mediation Server can be,
XML over TCP
XML over TCPS
XML over HTTP or
XML over HTTPS
The communication between the Central Server and the Distributed Mediation Server is pluggable and communication is possible in two modes, one-way communication and two-way communication. The two modes of communication are explained in Communication Modes section.
Two configuration files are needed for communication purposes, namely CommunicationInfo.xml present in both Central and Distributed Mediation Servers and NOCServerDetails.xml present in Distributed Mediation Server. These are specific to the remote management edition of Web NMS. The NOCServerDetails.xml file is explained in detail in Configuring Failover section and the parameter required for communication is mentioned in this section.
Configuration File for Communication
On initialization, the Distributed Mediation Server and Central Server read the CommunicationInfo.xml file present in the <DMS Server>/conf and the <Central Home>/conf directory respectively to initialize the communication mode. This file specifies the mode of communication, the implementation which defines the communication mode and also has the following configurable options:
Mode: This option specifies the mode of communication. The possible values are "1" for one-way communication and "2" for two-way communication.
InitImpl:
This option specifies the name of the class file that provides the implementation
for the mode specified in Mode option. The class specified in this option
should implement SPPCommInitIfc
.
MaxBufferSize: This option specifies the maximum number of data objects that can be held in the buffer and when the buffer is full, the objects are placed in a file. The default value is 25.
WriteInterval: This option specifies the interval at which the write operation is performed. The default value is 300 seconds. The value can be any positive integer or -1.
ReadInterval: This option specifies the interval at which the read operation is performed. The default value is 5 seconds. The value can be any positive integer or -1.
All the above-mentioned options have to be configured for the respective communication mode to be enabled. Read/Write interval configuration is explained in detail in Communication Modes section.
Data that is transferred through the communication framework is assigned a priority, in order to ensure that the important data is sent at the earliest. Data priority can be of the following four types:
HIGHPRIORITY
LOWPRIORITY
HIGHPRIORITY_SEND_IMMEDIATELY
SEND_IMMEDIATELY_WITHOUT_STORE
These priorities are exposed through a interface
called DataPriorityID. This interface defines the priorities available to
the modules for sending the data to the communication framework in the
Distributed Mediation Server. Based on this priority, the communication
framework will handle the respective data appropriately.
To store the data that are to be transferred between the Central Server and Distributed Mediation Server, both the servers are equipped with buffers. This is to enable a bulk transfer of data for every write interval, which is configurable through the writeInterval parameter in CommunicationInfo.xml present in the respective servers in the conf directory. This ensures that data is transferred between the servers at regular intervals and the interval can be set based on the network traffic.
The Distributed Mediation Server has two buffers, one of which acts as a high priority buffer and the other acts as the low priority buffer. The data is routed to the appropriate buffer based on the priority attached to it. When the write thread is invoked, for every write interval, the data in the high priority buffer is collected and sent to the Central Server. Once the high priority data transfer is complete, the low priority buffer data will be transferred.
The Central Server has one buffer corresponding to every Distributed Mediation Server that registers with it. Whenever data is to be transferred to a particular Distributed Mediation Server, the data is sent to the respective buffer and sent when the write thread is invoked.
When a server is down, the data to be transferred to that server is stored in the buffer temporarily and transferred when the communication between the servers is restored.
|
|
Note: The data with SEND_IMMEDIATELY_WITHOUT_STORE are lost if the Central server is down during transit. |
Whenever there is a communication failure, the Distributed Mediation Server tries to re-establish the connection by contacting the Central server at regular intervals. The read and write operations are blocked and a new thread for re-establishing the connection is started. This thread tries to connect to the Central server at regular intervals. The interval at which the Distributed Mediation Server tries to re-establish the connection can be configured by setting the value of ReEstablishInterval parameter present in the NOCServerDetails.xml file present in the <DMS Home>/conf directory. Once the connection is established, the re-establish thread will become inactive and the read / write threads blocked earlier, are released.
Status Polling is performed by the Central Server on a periodic basis to check if the Distributed Mediation Servers are up and running. The Distributed Mediation Servers keep updating the Central Server with its status at regular intervals. This interval is determined by the value of the parameter STATUSUPDATETIME of the RemoteProbe process defined in the NmsProcessesBE.conf file present in the <DMS Home>/conf directory. The status data sent by the Distributed Mediation Servers are updated in the database of the Central Server. At periodic intervals equivalent to the STATUSUPDATETIME interval, the Central Server checks its database to determine if the Distributed Mediation Server has updated the status. If the status update has not taken place then the Central Server signals a warning event and waits for another interval for the remote server to make the status update. The severity of this event increases.
|
|
