Metadata Folder

마지막으로 수정된 항목: 2009-03-10

The metadata folder stores the conference metadata (for example, the number of slides, the slide names, and the slide types) that is shared by the Web Conferencing Server with clients over Persistent Shared Object Model (PSOM). Under the metadata folder root, the Web Conferencing Server creates the following structure of subfolders:

• For each conference organizer, the Web Conferencing Server creates a separate folder below the metadata folder root. The organizer folder name is a hash value computed using the organizer URI.
• For each conference, the Web Conferencing Server creates a separate folder below the organizer subfolder. The conference folder name is the same as the conference ID.
• Metadata files for a conference are stored in the conference folder.

The following figure shows the structure of metadata folders for m organizers and n conferences for the first organizer.

The Web Conferencing Server creates these folders and subfolders when it receives a C3P addConference request from the Focus. If a folder for an organizer does not exist, the Web Conferencing Server creates a new organizer folder. If a folder for an organizer already exists, the Web Conferencing Server creates the conference subfolder below the existing organizer folder. If a folder for a conference does not exist, the Web Conferencing Server creates a new conference folder. If a conference folder already exists, the Web Conferencing Server saves the metadata files in the existing conference folder.

Sensitive information about conferences, including each conferences encryption key, is stored in the metadata folder. As a result, it is recommended that, during deployment, the administrator grants Read/Write permissions for the metadata folder only to the user group that will administer the Web Conferencing Server.

Contentmgr.xml File

In the metadata folder root, the Web Conferencing Server creates an XML file (Contentmgr.xml) that is used to coordinate the mechanism that cleans up the expired content. For example, if your organization deployed multiple instances of the Web Conferencing Server and all instances share the same metadata and content folders, the Contentmgr.xml file is used to monitor and determine which Web Conferencing Server is responsible for running the clean-up mechanism.

In the Contentmgr.xml file, you can find the fully qualified domain name (FQDN) of the Web Conferencing Server responsible for removing expired content from the folders. The Web Conferencing Server responsible for removing expired content periodically updates the Contentmgr.xml file with its own FQDN and a time stamp indicating the last time it updated the file. Meanwhile, other Web Conferencing Servers in the topology periodically read the file and verify the time stamp. If more than 10 minutes have passed since the last update, another Web Conferencing Server attempts to lock the file and write its own FQDN in the file to become the new owner of the clean-up process.