14.4 Understanding the Sender and Receiver
The Sender and the Receiver on the Inventory servers transfer the scan files from the lower-level Inventory servers to the higher-level Inventory servers. The Sender-Receiver uses the ZENworks Web Server to process the XML-RPC requests. The following sections contain more information:
Figure 14-1 depicts the processing done by the Sender-Receiver:
Figure 14-1 Sender-Receiver process
The processing done by the Sender-Receiver is as follows:
-
The Service Manager starts the Sender-Receiver component.
-
The Roll-Up Scheduler activates the Sender at the specified roll-up time.
-
The Sender moves the scan data files (.str) from the enterprise merge directory (entmergedir) to the enterprise push directory (entpushdir) and compresses the files as a .zip file.
-
Each .zip file is again compressed with the .prp file into a .zip file. The .prp file is an internal file containing information about the .zip file.
-
The Sender sends the .zip file from the \entpushdir directory to the Receiver on the next-level Inventory server.
-
The Receiver places the .zip files to the \entpushdir\zipdir directory.
-
The Receiver copies the .zip files to the \entpushdir directory and deletes the .zip files from the entpushdir\zipdir directory.
-
The Receiver copies the .zip files to the database directory (dbdir) if a database is attached to the Inventory server.
-
The Sender-Receiver logs the status in eDirectory.
14.4.1 Understanding the Sender
The Sender is a Java* component that runs on any Leaf Server or on the Intermediate Server. The Sender is a service loaded by the Service Manager. See Section 14.9, An Overview of the Inventory Components on the Inventory Server for a quick reference table of Inventory server components.
The flow of information from the Sender in the roll-up of inventory information is as follows:
-
The Service Manager starts the Sender on the Inventory server. At the specified time scheduled in the Roll-Up Schedule, the Sender moves the scan data files (.str) from the enterprise merge directory (entmergedir) to the enterprise push directory (entpushdir).
The Sender compresses these .str files in the \entpushdir directory of the Inventory server as a .zip file and then deletes the .str files. This .zip file is again compressed with the .prp file into a .zip file. The .prp file is an internal file containing information about the .zip file. For more information, see Understanding the Compressed Scan Data File.
-
The Sender creates a new record in the zeninvRollUpLog attribute of the Inventory Service object in eDirectory with the following details: server on which the Sender compresses the .str files and the name and size of the .zip file.
-
Based on the Discard Scan Data Time in the Inventory Service object properties of the Receiver, the Sender deletes the compressed .zip files in the \entpushdir directory that have been created earlier than the specified discard scan data time. This removes unwanted scan information being sent in the roll-up.
-
The Sender sends the compressed .zip files to the Receiver, with the oldest compressed files sent first.
-
The Sender after transferring the .zip file, deletes the compressed files in the \entpushdir directory.
-
After the roll-up of information, the Sender updates the zeninvRollUpLog attribute of the Inventory server on which the compressed file was created with the following details: Inventory server from which the Sender transmitted the file, name of the .zip file, time of transmission, total time taken to transmit the files, and the Inventory server to which it was sent.
In case of rolling up inventory information across trees, the roll-up status messages are logged into the first inventory server receiving the .zip file in the tree.
The status information for all actions of the Sender is logged in the Roll-Up Log and Server Status log. For more information, see Monitoring Server Inventory Using Status Logs.
If the Sender is unable to connect to the Receiver, the Sender retries to connect after 10 seconds. The time interval increases exponentially by a factor of 2. After 14 retries, the Sender stops trying to connect to the Receiver. The Sender retries for approximately 23 hours before it discontinues trying. The Sender does not process any other information while it is establishing the connection.
14.4.2 Understanding the Receiver
The Receiver is a Java component that runs on the Intermediate Server or on the Root Server. The Receiver is a service loaded by the Service Manager. See Section 14.9, An Overview of the Inventory Components on the Inventory Server for a quick reference table of Inventory server components.
On a Standalone Server, the Receiver is not loaded.
The processing done by the Receiver is as follows:
-
The Receiver receives the scan .zip file from the Sender and places the file in the \entpushdir\zipdir directory.
-
The Receiver copies the .zip file to the \entpushdir directory and deletes the .zip files from the \entpushdir\zipdir directory.
On an Intermediate Server, the file is placed in \entpushdir. On an Intermediate Server with Database, or an Intermediate Server with Database and Inventoried Servers, the file is placed in \entpushdir and copied to the Database Directory (dbdir).
-
The Receiver on the Root Server or the Root Server with Inventoried Servers receives the .zip files from the Senders and places the .zip files in the \entpushdir\zipdir directory. It copies the files to the \dbdir directory on the Inventory server.
-
The Receiver logs the status information in the Roll-Up log. For more information, see Monitoring Server Inventory Using Status Logs.
14.4.3 Understanding the Compressed Scan Data File
The Sender compresses the scan data files (.str) into a .zip file. This .zip file is again compressed with the .prp file into a .zip file. The .zip file (containing the .zip files and .prp) is named using the following naming conventions:
scheduledtime_inventoryservername_treename_storedstatus.zip
where scheduledtime refers to the date and time when the .zip file is created, inventoryservername refers to the Inventory server on which the .zip file was compressed, treename refers to the unique tree name in which the .zip file is currently located, storedstatus refers to the storage status of the .zip file, and ZIP is the file extension for the compressed files.
The storedstatus is represented by 0, 1, or 2. 0 indicates the .zip file has not yet been stored. 1 indicates the .zip file will be stored for the first time in the Inventory server. 2 indicates the .zip file has already been stored once.
The .zip filename changes depending on if the database is attached to the Inventory server.
The .zip file contains the .zip files and a property file. The property file is named using the following conventions:
scheduledtime_inventoryservername.prp
The property file contains the scheduled time, Inventory server name, and signature. The signature helps to authenticate the .zip file.
Each .zip file can contain a maximum of 50 .str files.
14.4.4 Sender-Receiver Directories
Table 14-3 provides a quick reference of the directories that the Sender-Receiver uses:
Table 14-3 List of directories used by Sender and Receiver