Scénario de duplication des composants Sujet parent

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

Scénario de duplication des composants du serveur

Fichiers de signatures complets sur le serveur OfficeScan
Version actuelle : 171
Autres versions disponibles :
169
167
165
161
159
  
Dernière version sur le serveur ActiveUpdate
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
        
  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
    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 clients qui n'ont pas téléchargé les fichiers de signatures incrémentiels précédents 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 fichier de signatures complet et les 14 fichiers de signatures incrémentiels sont mis à la disposition des clients.