Scénario de duplication des composants

Pour comprendre le processus de duplication des composants pour le serveur, reportez-vous au scénario suivant :

1. Le serveur OfficeScan compare la version actuelle de son fichier de signatures complet avec la dernière version disponible sur le serveur ActiveUpdate. Si la différence entre les deux versions est inférieure ou égale à 14, le serveur ne télécharge que le fichier de signatures incrémentiel qui correspond à la différence entre les deux versions.

   Remarque :

   si la différence est supérieure à 14, le serveur télécharge automatiquement la version complète du fichier de signatures et 14 fichiers de signatures incrémentiels.

   Voici un exemple :

   • La différence entre les versions 171 et 175 est de 2. En d'autres termes, le serveur ne dispose pas des versions 173 et 175.

   • Le serveur télécharge les fichiers de signatures incrémentiels 171.175. Le fichier de signatures incrémentiel correspond à la différence entre les versions 171 et 175.

2. Le serveur fusionne le fichier de signatures incrémentiel avec son fichier de signatures complet actuel pour générer le fichier de signatures complet le plus récent.

   Voici un exemple :

   • Sur le serveur, OfficeScan fusionne la version 171 avec le fichier de signatures incrémentiel 171.175 pour générer la version 175.

   • Le serveur dispose d'un fichier de signatures incrémentiel (171.175) et du fichier de signatures complet le plus récent (version 175).

3. Le serveur génère des fichiers de signatures incrémentiels en fonction des autres fichiers de signatures complets disponibles sur le serveur. Si le serveur ne génère pas ces fichiers de signatures incrémentiels, les agents qui n'ont pas téléchargé de version antérieure de ces fichiers procèdent automatiquement au téléchargement du fichier de signatures complet, ce qui entraîne une augmentation du trafic réseau.

   Voici un exemple :

   • Le serveur dispose des versions 169, 167, 165, 163, 161 et 159. Il peut donc générer les fichiers de signatures incrémentiels suivants :

     169.175, 167.175, 165.175, 163.175, 161.175, 159.175

   • Dans la mesure où le serveur dispose déjà du fichier de signatures incrémentiel 171.175, il n'a pas besoin d'utiliser la version 171.

   • Le serveur dispose maintenant de 7 fichiers de signatures incrémentiels :

     171.175, 169.175, 167.175, 165.175, 163.175, 161.175, 159.175

   • Le serveur conserve les 7 derniers fichiers de signatures complets (versions 175, 171, 169, 167, 165, 163, 161). Il supprime toute version antérieure (version 159).

4. Le serveur compare ses fichiers de signatures incrémentiels actuels avec ceux disponibles sur le serveur ActiveUpdate. Le serveur télécharge les fichiers de signatures incrémentiels dont il ne dispose pas.

   Voici un exemple :

   • Le serveur ActiveUpdate dispose de 14 fichiers de signatures incrémentiels :

     173.175, 171.175, 169.175, 167.175, 165.175, 163.175, 161.175, 159.175, 157.175, 155.175, 153.175, 151.175, 149.175, 147.175

   • Le serveur OfficeScan dispose de 7 fichiers de signatures incrémentiels :

     171.175, 169.175, 167.175, 165.175, 163.175, 161.175, 159.175

   • Le serveur OfficeScan procède au téléchargement de 7 fichiers de signatures incrémentiels supplémentaires :

     173.175, 157.175, 155.175, 153.175, 151.175, 149.175, 147.175

   • Le serveur dispose maintenant de tous les fichiers de signatures incrémentiels disponibles sur le serveur ActiveUpdate.

5. Le dernier fichier de signatures complet et les 14 fichiers de signatures incrémentiels sont mis à la disposition des agents.