Understanding the Sender-Receiver

The Sender and the Receiver on the servers transfer the scan files from the lower-level servers to the higher-level servers. The following sections contain more information:

The following illustration depicts the processing done by the Sender-Receiver.


Processing done by the Sender-Receiver as it transfers files from one server to another server

The processing done by the Sender-Receiver is as follows:

  1. The Service Manager starts the Sender-Receiver component.
  2. The Roll-Up Scheduler activates the Sender at the specified roll-up time.
  3. 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.
  4. The Sender sends the .ZIP file from the ENTPUSHDIR directory to the Receiver on the next-level server.
  5. The Sender on the Intermediate Server sends the .ZIP file to the Receiver on the next-level server.
  6. The Receiver copies the .ZIP files to the ENTPUSHDIR directory.
  7. The Receiver copies the .ZIP files to the database directory (DBDIR).
  8. The Sender-Receiver logs the status in eDirectory.

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 Inventory Components on Servers for a quick reference table of server components.

The flow of information from the Sender in the roll-up of scan data is as follows:

  1. The Service Manager starts the Sender on the 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 server as a .ZIP file and then deletes the .STR files. For more information, see Understanding the Compressed Scan Data File .

  2. The Sender creates a new record in the zeninvRollUpLog attribute of the Inventory Service object (ZenInvservice) in eDirectory with the following details: server on which the Sender compresses the STR files and the name and size of the .ZIP file.
  3. 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.
  4. The Sender sends the compressed .ZIP files to the Receiver, with the oldest compressed files sent first.
  5. The Sender receives an acknowledgment from the Receiver that a .ZIP file was properly received and then deletes the compressed files in the ENTPUSHDIR directory.
  6. After the roll-up of data, the Sender updates the zeninvRollUpLog attribute of the server on which the compressed file was created with the following details: 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 server to which it was sent.

    The status information for all actions of the Sender is logged in the Roll-Up Log and Server Status log. For more information, see Troubleshooting Workstation Inventory with 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 data while it is establishing the connection.


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 Inventory Components on Servers for a quick reference table of server components.

The processing done by the Receiver is as follows:

  1. On successfully establishing communication with the Sender, the Receiver receives the scan .ZIP file from the Sender. The file is placed in the enterprise push directory (ENTPUSHDIR).

    On an Intermediate Server, the file is placed in ENTPUSHDIR. On an Intermediate Server with Database, or an Intermediate Server with Database and Workstations, the file is placed in ENTPUSHDIR and copied to the Database Directory (DBDIR).

  2. The Receiver on the Root Server or the Root Server with Workstations receives the .ZIP files from the Senders and copies the files to the DBDIR directory on the server.
  3. The Receiver logs the status information in the Roll-Up log. For more information, see Troubleshooting Workstation Inventory with Status Logs .

Understanding the Compressed Scan Data File

The Sender compresses the scan data files (.STR) into a .ZIP file. The .ZIP file is named using the following naming conventions:

scheduledtime_inventoryservername_siteID_sitename.ZIP

where scheduledtime refers to the date and time when the Sender is scheduled for roll-up of scan information, inventoryservername refers to the inventory server on which the .ZIP file was compressed, siteID refers to the identification of the database that is attached to the inventory server, sitename refers to the unique site name of the database specified during installation, and ZIP is the file extension for the compressed files.

The .ZIP filename changes depending on if the database is attached to the server. If the database is not attached to the server, the file is named as follows:

scheduledtime_inventoryservername_NOTSTOREDINDATABASETILLNOW_NULL.ZIP

The .ZIP file contains the .STR files and a property file. The property file is named using the following conventions:

scheduled_time_inventoryservername.PRP

The property file identifies the information for roll-up from the enterprise push directory (ENTPUSHDIR) to the next-level server. 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 1,000 .STR files.


Sender-Receiver Directories

The following table provides a quick reference of the directories that the Sender-Receiver uses:

Server Sender Receiver ENTMERGDIR ENTPUSHDIR DBDIR

Leaf Server, Leaf Server with Database

Runs on this server

--

  • Sender moves the STR files to the ENTPUSHDIR.

  • Sender compresses the .STR files as a .ZIP file.
  • Sender deletes the .STR files.
  • Sends the .ZIP file to the next-level server.

--

Intermediate Server

Runs on this server

Runs on this server

--

  • Receiver receives the .ZIP files from the lower-level server in this directory.
  • Sender sends the .ZIP files to the next-level server.

--

Intermediate Server with Workstations

Runs on this server

Runs on this server

  • Sender moves the .STR files to the ENTPUSHDIR.

  • Receiver receives the .ZIP files from the lower-level server in this directory.
  • Sender compresses the .STR files in to .ZIP files.
  • Sender deletes the .STR files.
  • Sender sends the .ZIP files to the next-level server.

 

Intermediate Server with Database

Runs on this server

Runs on this server

--

  • Receiver receives the .ZIP files from the lower-level server in this directory.
  • Sender sends the .ZIP file to the next-level server.

  • Receiver copies the file in this directory.

Intermediate Server with Database and Workstations

Runs on this server

Runs on this server

  • Sender moves the .STR files to the ENTPUSHDIR.

  • Receiver receives the .ZIP files from the lower-level server in this directory.
  • Sender compresses the .STR files as a .ZIP file.
  • Sender deletes the .STR files.
  • Sender sends the .ZIP file to the next-level server.

  • Receiver copies the file in this directory.

Root Server,

Root Server with Workstations

--

Runs on this server

--

--

  • Receiver receives the .ZIP files from the lower-level server in this directory.

On the Standalone Server, the Receiver is not loaded.