Brevet FR2728088A1 — publié le 19960614

Procédé d'échange d'informations en mode client/serveur, entre stations reliées par un réseau de communication La présente invention se rapporte au domaine technique de l'échange d'informations en mode client-serveur, entre stations reliées par un réseau de communication. Elle trouve une application générale dans un procédé dans lequel a) on prévoit un réseau formé d'un milieu de communication, et d'une pluralité de stations associées chacune à un coupleur sur ledit milieu, b) on prévoit dans ce réseau au moins une station-serveur, et c) on munit chaque coupleur d'un protocole de communication de réseau, permettant le traitement de requêtes de consultation de fichier-ressource entre certaines des stations dites stations-client et la station-serveur. Dune manière générale, un serveur permet l'accès à des fichiers pour des clients qui en font la requête. Le serveur est une machine qui stocke d'une manière unique et centrale un grand nombre de fichiers pour réduire les coûts de mise en oeuvre (une seule mémoire) et simplifier l'administration des fichiers (une seule zone à mettre à jour). On connaît un protocole de communication, appelé NFS pour Network File System (système de fichiers en réseau), développé par la société américaine SUN MICROSYSTEMS, INC, et dans lequel le serveur offre en partage pour ses clients une pluralité de fichiers rangés selon une arborescence de fichiers choisie. Dans ce protocole, l'arborescence des fichiers est construite à partir de l'identification de facon univoque de chacune fichier par une étiquette, appelée encore file handle". Cette identification est réalisée par le serveur. En pratique, un client qui souhaite accéder à un fichier de l'arborescence doit au préalable requérir l'étiquette de la racine de cette arborescence (root file handle). Le serveur ne garde pas de trace de la distribution des fichiers (informations et données) à la destination des clients (stateless). Dans ces conditions, il ne peut pas prévenir les clients lors des modifications apportées aux fichiers au niveau du serveur. Par conséquent, les clients interrogent régulièrement le serveur, pour vérifier que les données et informations qu'ils ont en mémoire sont à jour. I1 en résulte un trafic important et inutile dans la mesure où les fichiers centralisés dans le serveur ont la propriété d'être d'une grande stabilité. De plus, l'arrêt du service offert par le serveur, par exemple en cas de panne de celui-ci, influence directement le bon fonctionnement des clients, et ce avec d'autant plus de sévérité et d'acuité que les fichiers centralisés sont souvent critiques pour le fonctionnement desdits clients. I1 est à remarquer que dans la majorité des cas, le redémarrage du serveur assure, sans aucune autre intervention, la reprise normale de l'activité des clients. Toutefois, certains incidents, tels que le changement sur le serveur d'un disque support des fichiers centralisés, ne sont pas transparents pour les clients. En effet, les étiquettes des fichiers dépendent en général de la position des fichiers sur le disque support central. I1 en résulte que le changement d'emplacement des fichiers au niveau du serveur rend faux les étiquettes déjà distribuées aux clients et nécessitent par conséquent leur correction. Une solution pourrait consister à modifier le protocole de communication pour remédier à ces inconvénients. Toutefois, cela serait difficilement envisageable dans la mesure où ces modifications détruiraient l'interopérabilité dudit protocole. L'invention a pour but d'apporter une solution à ces problèmes sans pour autant détruire l'interopérabilité du protocole de communication. Un autre but de l'invention vise à fournir un procédé de mise en oeuvre facile et simple, ne nécessitant aucune modification des couches logiciels existantes gérant le protocole de communication, en particulier le protocole NFS. Ce résultat est obtenu par le procédé décrit ci-avant et qui est caractérisé par le fait qu'il comprend les étapes suivantes d) au niveau de certaines au moins des stations, dl) entretenir localement un fichier auxiliaire représentatif dune correspondance entre une désignation d'un fichierressource et d'une part un emplacement-substitut de celui-ci, d'autre part une condition-clef pour le recours à cet emplacement-substitut, d2) prévoir un serveur émulé propre à dialoguer selon ledit protocole pour traiter des requêtes de consultation de fichier-ressource, d3) au niveau du coupleur entre la station et le réseau, prévoir un mécanisme d'interception des requêtes de consultation de fichier-ressource, en les re-dirigeant vers le serveur local émulé, d4) au niveau du serveur émulé, accéder au fichier auxiliaire, et recevoir les requêtes interceptées, pour si ladite condition-clef pour le fichier désiré est vraie, traiter la requête avec ltemplacement-substitut, sinon adresser à la station serveur une requête dérivée tendant à obtenir l'accès au fichier désiré. Un tel procédé a l'avantage de protéger d'une manière générale les clients contre une panne du serveur dans un environnement client/serveur tout en conservant l'interopérabilité du protocole de communication. Selon un mode de mise en oeuvre particulier du procédé selon l'invention, il comprend en outre les étapes suivantes i) au niveau de la station-serveur, ranger les fichiersressource selon une arborescence choisie, ii) au niveau du serveur émulé, stocker une partie au moins des fichiers-ressource dans leur emplacement-substitut respectif selon l'arborescence choisie, iii) définir la condition-clef pour le recours à l'emplace- ment-substitut d'un fichier-ressource selon la disponibilité et l'obsolescence dudit fichier-ressource, iv) entretenir le fichier auxiliaire au niveau de la stationserveur, en fonction de toute modification apportée aux fichiers ressource stockés dans la station serveur, vi) prévoir des échanges de données sur le réseau, à l'initiative de la station-client, pour la consultation du fichier auxiliaire de la station-serveur et pour la mise à jour des emplacements-substitut du ou des serveurs émulés en fonction de l'état dudit fichier auxiliaire. I1 est à remarquer que dans ce mode de mise en oeuvre particulier de l'invention, le serveur émulé joue le rôle d'antémémoire de façon à améliorer les performances du réseau en diminuant le nombre de requêtes vers le serveur. Le fichier auxiliaire joue ici le rôle de fichier de synchronisation pour identifier toute modification apportée aux fichiers côté serveur, et mettre à jour les fichiers stockés dans le serveur émulé. Selon un autre mode de mise en oeuvre particulier du procédé selon l'invention, il comprend en outre les étapes suivantes i) au niveau de la station-serveur, rangés les fichiersressource selon une arborescence choisie, ii) prévoir au moins une station-serveur supplémentaire et stocker dans celle-ci, une partie au moins des fichiersressource dans leur emplacement-substitut respectif selon l arborescence choisie, iii) définir la condition-clef pour le recours à l'emplacement-substitut d'un fichier-ressource selon l'absence/présence d'une correspondance entre l'emplacement-substitut et la désignation du fichier-ressource, et iv) entretenir le fichier auxiliaire au niveau du serveur émulé, en fonction de toute modification apportée à la correspondance entre l'emplacement-substitut et la désignation de chaque fichier-ressource. I1 est à remarquer que dans ce mode de mise en oeuvre particulier, le serveur émulé joue le rôle de commutateur en dirigeant la requête de consultation de fichier vers un serveur disponible, ce qui permet d'améliorer la fiabilité du réseau. Le fichier auxiliaire joue ici le rôle d'arbre de correspondance pour diriger toute requête de consultation de fichier vers un serveur disponible. D'autres caractéristiques et avantages de l'invention apparaîtront à la lumière de la description détaillée ciaprès et des dessins annexés dans lesquels - la figure 1 est un synoptique illustrant le réseau de communication dans lequel est mis en oeuvre le procédé selon l'invention - la figure 2 est un organigramme illustrant les étapes du procédé côté client, dans le cadre où le serveur émulé joue le rôle d'antémémoire - la figure 3 est un organigramme illustrant les étapes relatives à la validation de l'antémémoire en fonction de l'état du fichier auxiliaire selon l'invention ; et - la figure 4 est un organigramme illustrant, les étapes relatives au fonctionnement du serveur émulé jouant le rôle de commutateur selon l'invention. Le dispositif dans lequel le procédé de l'invention est mis en oeuvre est représenté à la figure 1. I1 s'agit d'un réseau formé d'un milieu de communication 2, par exemple de type ETHERNET (Marque déposée) et d'une pluralité de stations 4, 6 associées chacune à un coupleur 8 sur ledit milieu 2. Par exemple, la station 6 est ici une station-serveur. Chaque coupleur 8 est muni d'un protocole de communication de réseau permettant le traitement de requête de consultation de fichier-ressource entre certaines des stations dites stations-client et la station-serveur. Chaque station 4, 6 pour communiquer en environnement client/serveur comprend des couches logiciels 10 de type IP pour "INTERNET PROTOCOL", et 12 de type TCP/UDP pour "Trans- mission Control Protocol/User Datagram Protocol". La station-client 4 comprend une mémoire de masse (non représentée) de l'ordre de 500 mégaoctets. De son côté, la station-serveur comprend une mémoire de masse de l'ordre 8 Gigaoctets. Des mémoires vives (non représentées) de 6 à 32 mégaoctets sont également prévues au niveau de chaque station. Le serveur permet l'accès aux fichiers stockés dans la mémoire de masse du serveur et attend les requêtes REQ venant des clients. Le serveur traite ces requêtes REQ et envoient la réponse RES aux clients en passant à travers le milieu de communication 2. Des échanges de données ECH sont prévus pour la mise en place et le fonctionnement du mode client/serveur. Les coupleurs permettent d'aiguiller les messages des clients vers les serveurs et vice versa. Le procédé selon l'invention trouve une application particu lière dans le protocole de communication, appelé NFS et dans lequel le serveur offre en partage pour ses clients une pluralité de fichiers rangés selon une arborescence de fichiers classique en milieu informatique articulée autour d'une racine et de branches répertoires. Dans ce protocole, l'arborescence des fichiers est construite à partir de l'identification de façon univoque de chaque fichier par une étiquette, appelée encore "file handle". Cette identification est réalisée par le serveur. Les mécanismes de constitution de cette étiquette sont propres au serveur. I1 est donc très difficile à une autre machine de générer de façon fiable des étiquettes identiques à celles du serveur. Un client qui souhaite accéder à un fichier de l'arborescence offerte par le serveur, doit au préalable obtenir le file handle de la racine de cette arborescence : le root file handle. La requête qui permet d'obtenir ce root file handle a la particularité d'être la seule à ne pas s'appuyer sur un autre file handle. Toutes les autres requêtes se font sur la base d'un file handle obtenu lors d'une requête antérieure. On distingue quatre sortes de requêtes dans le protocole NFS. La première catégorie de requêtes est celle appelée look up" qui permet de demander le file handle d'un fichier dont on connaît le nom et le file handle du répertoire qui le contient. C'est cette requête qui permet d'appréhender l'organisation arborescente. La seconde catégorie de requêtes est celle appelée "readlink" qui permet de demander le nom du lien contenu dans un fichier dont on connaît le file handle. La troisième catégorie de requêtes est celle appelée "Ge- tattr" qui permet de demander les informations d'état ou attributs d'un fichier dont on connaît le file handle. Enfin, la quatrième catégorie de requêtes est celle appelée "read" qui permet de demander un bloc de données d'un fichier dont on connaît le file handle. Le serveur ne garde pas de trace de la distribution des fichiers (informations et données) à la destination des clients. Dans ces conditions, il ne peut pas prévenir les clients lors des modifications apportées aux fichiers stockés au niveau du serveur. Par conséquent, les clients interrogent régulièrement le serveur, pour vérifier que les données et informations qu'ils ont en mémoire sont à jour. I1 en résulte un trafic important et inutile dans la mesure où les fichiers centralisés dans le serveur ont la propriété d'être d'une grande stabilité. De plus, l'arrêt du service offert par le serveur, par exemple en cas de panne de celui-ci, influence directement le bon fonctionnement des clients, et ce avec d'autant plus de sévérité et d'acuité que les fichiers centralisés sont souvent critiques pour le fonctionnement desdits clients. I1 est à remarquer que dans la majorité des cas, le redémarrage du serveur assure, sans aucune autre intervention, la reprise normale de l'activité des clients. Toutefois, certains incidents, tels que le changement sur le serveur d'un disque support des fichiers centralisés, ne sont pas transparents pour les clients. En effet, les étiquettes des fichiers dépendent en général de la position des fichiers sur le disque support central. I1 en résulte que le changement d'emplacement des fichiers au niveau du serveur rend faux les étiquettes déjà distribuées aux clients et nécessitent par conséquent leur correction. Le service ou protocole NFS ne propose pas de mécanisme pour protéger le client contre de tels incidents, par exemple une panne du serveur. Le procédé selon l'invention permet de résoudre ces problèmes tout en conservant l'interopérabilité du protocole NFS. La solution générale selon l'invention consiste notamment - à prévoir un serveur émulé SEM, au niveau d'au moins certaines stations 4, ledit serveur émulé étant propre à dialoguer selon ledit protocole pour traiter des requêtes de consultation de fichier-ressource au niveau du coupleur entre la station et le réseau, - à utiliser le mécanisme d'interception des requêtes de consultation de fichier-ressource disponible dans le protocole IP, en les re-dirigeant vers le serveur local émulé, et - à faire jouer au serveur émulé le rôle, soit d'antémémoire pour réduire le trafic, soit de commutateur pour pallier la panne d'un serveur. En référence à la figure 2, il est prévu, au niveau du serveur émulé SEM, de stocker tout d'abord (étape 100) une partie au moins des fichiers-ressource Fi dans leur emplacement-substitut ESi respectif, avec i nombre entier réglable et limité en pratique à quelques milliers. En pratique, il s'agit, au niveau du serveur émulé SEM, de conserver les attributs d'un grand nombre i de fichiers Fi, les attributs étant par exemple : le nom du propriétaire du fichier, la taille du fichier, les adresses de données, la date de la dernière modification du fichier, etc. Le serveur émulé a une antémémoire d'une capacité de l'ordre de 128 kilooctets, réglable selon les applications. Le fonctionnement du procédé selon l'invention lorsque le serveur émulé joue le rôle d'antémémoire est le suivant. Lors de l'étape 110, on intercepte les requêtes de consultation REQ à l'aide du mécanisme INT, par exemple du type LOOP BACK disponible dans le protocole IP. Seules les requêtes de type "look up, read link et getattr" sont susceptible d'être interceptées. Les autres requêtes sont transmises directement au serveur distant. Lors de l'étape 120, au niveau du serveur émulé, on reçoit la requête interceptée et on accède au fichier auxiliaire. Si la condition-clef pour le fichier désiré est vraie, c'est -dire si le fichier désiré est contenu dans l'antémémoire (Fi dans ESi), on traite la requête avec l'emplacementsubstitut ESi (étape 140), c'est-à-dire la réponse RES est donnée par le serveur émulé local. Sinon (étape 150), la requête est transmise au serveur distant dont la réponse RES (étape 160) est enregistrée (étape 170) dans l'antémémoire du serveur émulé. En présence du fichier Fi dans le serveur distant, le fichier désiré est stocké dans l'emplacement-substitut ESi du serveur émulé. Sinon, on mémorise dans le serveur émulé une information relative à cette absence du fichier Fi dans le serveur distant. I1 est à remarquer que ce mécanisme limite de façon très notable l'utilisation du serveur distant. Toutefois, il pose un problème de synchronisation en cas de modification de fichiers sur le serveur distant. Pour assurer cette indispensable synchronisation, il est prévu, selon l'invention, d'entretenir un fichier auxiliaire représentatif d'une correspondance entre une désignation d'un fichier-ressource et, d'une part un emplacement-substitut ESi de celui-ci, d'autre part une condition clé pour le recours à cet emplacement-substitut. Dans le cadre de l'antémémoire, la condition clé pour le recours à l'emplacement-substitut d'un fichier-ressource est la disponibilité et l'obsolescence dudit fichier. Au niveau du serveur, il est prévu d'entretenir le fichier auxiliaire en fonction de toute modification apportée au fichier-ressource stocké dans la station-serveur. Par ailleurs, il est prévu des échanges de données sur le réseau à l'initiative de la station-client pour la consultation du fichier auxiliaire de la station-serveur et pour la mise à jour des emplacements-substitut du ou des serveurs émulés en fonction de l'état dudit fichier auxiliaire. D'une manière plus précise, l'étape relative à l'entretien du fichier auxiliaire comprend les étapes suivantes (figure 3) - au niveau de la station-serveur, modifier le fichier auxiliaire en présence de toute modification apportée à au moins un fichier-ressource stocké dans la station-serveur ;; - au niveau du serveur émulé (étape 200), après une temporisation prédéterminée ou un événement prédéterminé, générer une requête de consultation du fichier auxiliaire à destination du serveur distant (étape 210) - au niveau du serveur distant, recevoir la requête de consultation du fichier auxiliaire et délivrer une réponse représentative de l'état du fichier auxiliaire par rapport à son état lors de la précédente requête de consultation du fichier auxiliaire (étape 220) - au niveau du serveur émulé, en présence d'une réponse représentative d'une différence de l'état du fichier auxi liaire par rapport à son état précédent, invalider la totalité de l'antémémoire contenant la recopie des fichiersressource (étape 230), et générer une requête de mise à jour de l'antémémoire à destination du serveur distant (étape 240) - au niveau du serveur distant, recevoir la requête de mise à jour du contenu de l'antémémoire du serveur émulé et transmettre le contenu de fichiers-ressource à destination du serveur émulé (étape 250) - enfin, au niveau du serveur émulé, en présence d'une réponse représentative d'une égalité de l'état du fichier auxiliaire par rapport à son état précédent, ou en réponse à la mise à jour de l'antémémoire émanant du serveur distant, valider l'image locale des fichiers-ressource (étape 260). En pratique, l'état du fichier auxiliaire est demandé périodiquement (périodicité réglable, en pratique toutes les 128 requêtes ou toutes les 30 secondes d'activité) par le serveur émulé local au serveur distant par, par exemple une requête de type getattr. En cas de changement d'état de ce fichier auxiliaire, l'antémémoire est réputée vide et le processus de mémorisation dans l'antémémoire commence. I1 est à remarquer qu'une simple modification du fichier auxiliaire sur le serveur distant provoque une mise à jour de l'ensemble des clients dans un délai maximum de 30 secondes. En référence à la figure 4, on a représenté un organigramme qui illustre le procédé selon l'invention dans lequel le serveur émulé joue le rôle de commutateur. En bref, si l'on dispose de deux ou plus serveurs pour une arborescence donnée, le serveur émulé est capable, en cas de non réponse du serveur distant auquel il vient de s'adresser, de soumettre la même requête à un autre serveur. Ceci est rendu possible selon l'invention par le fait que les étiquet tes distribuées par le serveur local sont totalement indépendantes du serveur distant. Pour obtenir cette indépendance, et pouvoir dialoguer avec le serveur distant, le serveur émulé local conserve une table de correspondance entre les étiquettes qu'il distribue et celles fournies effectivement par les serveurs. Cette table se construit dynamiquement en fonction des requêtes look up générées par le client. Plus précisément, il est prévu au moins une autre stationserveur, et dans celle-ci, il est prévu de stocker une partie au moins des fichiers-ressource dans leur emplacementsubstitut respectif selon l'arborescence choisie. On définit la condition clé pour le recours à lemplacement- substitut d'un fichier-ressource selon l'établissement d'une correspondance entre ledit emplacement-substitut et la désignation du fichier-ressource. Enfin, on entretient un fichier auxiliaire au niveau du serveur émulé, en fonction de toute modification apportée à ladite correspondance entre l'emplacement-substitut et la désignation du fichier-ressource. I1 y a lieu de remarquer que le fichier auxiliaire est ici entretenu au niveau du serveur émulé, tandis qu'il est entretenu au niveau du serveur distant lorsque le serveur émulé joue le rôle d'antémémoire. En pratique, l'entretien du fichier auxiliaire au niveau du serveur émulé comprend les étapes suivantes (figure 4) - au niveau du serveur émulé, en présence d'une correspondance non établie entre l'emplacement-substitut et la désignation du fichier-ressource (étape 300), il est prévu de générer une requête de consultation de fichier à destination du serveur distant (étape 310) - au niveau du serveur distant, il est prévu de recevoir la requête de consultation et de consulter la nouvelle correspondance entre l'emplacement-substitut et la désignation du fichier-ressource. Cette nouvelle correspondance est obtenue grâce à la désignation du fichier-ressource accompagnant la requête de consultation.On transmet alors la nouvelle correspondance à destination du serveur émulé (étape 320) - enfin, au niveau du serveur émulé, on reçoit et on enregistre la nouvelle correspondance (étape 330), et on remplace, dans la requête de consultation du fichier, l'ancienne correspondance par la nouvelle correspondance (étape 340). I1 est à remarquer que les deux fonctionnalités antémémoire et commutateur décrites ci-avant sont totalement indépendantes lune de l'autre et peuvent donc fonctionner séparément. Elles sont par exemple implantées dans les couches 5 ou 6 de la norme OSI. Dune manière générale, dans le cas de l'antémémoire, il y a interposition au niveau de la station-client d'un logiciel simple, qui permet, sans modification du système d'exploitation, de réduire les délais d'attente au niveau du client et de diminuer ainsi la charge sur le serveur. Ce résultat est obtenu notamment par la création d'un fichier auxiliaire, dit de synchronisation au niveau du serveur, qui permet de provoquer la synchronisation de tous les clients. Dans le cas du commutateur, il est prévu d'interposer, au niveau de la station-client, un logiciel simple qui permet sans modification du système d'exploitation, de distribuer des étiquettes indépendantes des serveurs, et de permettre ainsi de s'adresser à plusieurs serveurs. Revendications 1. Procédé d'échange d'informations en mode client-serveur, entre stations reliées par un réseau de communication, dans lequel a) on prévoit un réseau formé d'un milieu de communication (2), et d'une pluralité de stations (4, 6) associées chacune à un coupleur (8) sur ledit milieu (2), b) on prévoit dans ce réseau au moins une station-serveur (6), c) on munit chaque coupleur (8) d'un protocole de communication de réseau, permettant le traitement de requêtes de consultation (REQ) de fichier-ressource (Fi) entre certaines des stations dites stations-client et la station-serveur, caractérisé en ce qu'il comprend les étapes suivantes d) au niveau de certaines au moins des stations, dl) entretenir localement un fichier auxiliaire représentatif d'une correspondance entre une désignation d'un fichierressource et d'une part un emplacement-substitut (ESi) de celui-ci, d'autre part une condition-clef pour le recours à cet emplacement-substitut (ESi), d2) prévoir un serveur émulé (SEM) propre à dialoguer selon ledit protocole pour traiter des requêtes de consultation de fichier-ressource, d3) au niveau du coupleur (8) entre la station (4) et le réseau (2), prévoir un mécanisme d'interception (INT) des requêtes de consultation de fichier-ressource, en les redirigeant vers le serveur local émulé (SEM), d4) au niveau du serveur émulé (SEM), accéder au fichier auxiliaire, et recevoir les requêtes interceptées, pour si ladite condition-clef pour le fichier désiré est vraie, traiter la requête avec l'emplacement-substitut,(ESi) sinon adresser à la station serveur une requête dérivée tendant à obtenir l'accès au fichier désiré. 2. Procédé selon la revendication 1, caractérisé en ce qu'il comprend en outre les étapes suivantes i) au niveau de la station-serveur, ranger les fichiersressource (Fi) selon une arborescence choisie, ii) au niveau du serveur émulé (SEM), stocker une partie au moins des fichiers-ressource (Fi) dans leur emplacementsubstitut respectif (ESi) formant antémémoire, iii) définir la condition-clef pour le recours à I'emplacement-substitut d'un fichier-ressource selon la disponibilité et l'obsolescence dudit fichier-ressource, iv) entretenir le fichier auxiliaire au niveau de la stationserveur, en fonction de toute modification apportée aux fichiers ressource stockés dans la station serveur, v) prévoir des échanges de données sur le réseau, à l'initiative de la station-client, pour la consultation du fichier auxiliaire de la station-serveur et pour la mise à jour des emplacements-substitut (ESi) du ou des serveurs émulés (SEM) en fonction de l'état dudit fichier auxiliaire. 3. Procédé selon la revendication 2, caractérisé en ce que l'étape iv) comprend les étapes suivantes ivl) au niveau de la station-serveur, modifier le fichier auxiliaire en présence de toute modification apportée à au moins un fichier-ressource stocké dans la station serveur, en ce que l'étape v) comprend les étapes suivantes vl) au niveau du serveur émulé (SEM), après une temporisation prédéterminée ou un événement prédéterminé, générer une requête de consultation du fichier auxiliaire à destination du serveur distant, v2) au niveau du serveur distant, recevoir la requête de consultation du fichier auxiliaire et délivrer une réponse représentative de l'état du fichier auxiliaire par rapport à son état lors de la précédente requête de consultation du fichier auxiliaire, v3) au niveau du serveur émulé, en présence d'une réponse représentative d'une différence de l'état du fichier auxiliaire par rapport à son état précédent, invalider la totalité de l'antémemoire contenant la recopie des fichiers ressource, et générer une requête de mise à jour de l'antémémoire à destination du serveur distant, v4) au niveau du serveur distant, recevoir la requête de mise à jour de l'antémémoire du serveur émulé et transmettre le contenu du fichier-ressource désiré à destination du serveur émulé, et vS) au niveau du serveur émulé, en présence d'une réponse représentative d'une égalité de l'état du fichier auxiliaire par rapport à son état précédent ou en réponse à la mise à jour de l'antémémoire émanant du serveur distant, valider l'image locale des fichiers ressource. 4. Procédé selon la revendication 1, caractérisé en ce qu'il comprend en outre les étapes suivantes 1) au niveau de la station-serveur, ranger les fichiersressource selon une arborescence choisie, 2) prévoir au moins une autre station-serveur et dans celleci, stocker une partie au moins des fichiers-ressource dans leur emplacement-substitut respectif selon l'arborescence choisie, 3) définir la condition-clef pour le recours à l'emplacementsubstitut d'un fichier-ressource selon l'établissement d'une correspondance entre l'emplacement-substitut et la désignation du fichier-ressource, et 4) entretenir le fichier auxiliaire au niveau du serveur émulé, en fonction de toute modification apportée à ladite correspondance entre 1 'emplacement-substitut et la désignation du fichier-ressource. 5. Procédé selon la revendication 4, caractérisé en ce que l'étape 4 comprend les étapes suivantes 41) au niveau du serveur émulé, en présence d'une correspondance non établie, générer une requête de consultation de fichier à destination d'un serveur distant, 42) au niveau du serveur distant, recevoir la requête de consultation, consulter la nouvelle correspondance entre l'emplacement-substitut et la désignation du fichier-ressource, obtenue grâce à la désignation du fichier-ressource accompagnant la requête de consultation, et transmettre ladite nouvelle correspondance à destination du serveur émulé, 43) au niveau du serveur émulé, recevoir et enregistrer dans l'arbre de correspondance, ladite nouvelle correspondance entre l'emplacement-substitut et la désignation du fichierressource, et remplacer dans la requête de consultation de fichier, l'ancienne correspondance par la nouvelle correspondance.