FR2728088A1 - Procede d'echange d'informations en mode client/serveur, entre stations reliees par un reseau de communication - Google Patents
Procede d'echange d'informations en mode client/serveur, entre stations reliees par un reseau de communication Download PDFInfo
- Publication number
- FR2728088A1 FR2728088A1 FR9415013A FR9415013A FR2728088A1 FR 2728088 A1 FR2728088 A1 FR 2728088A1 FR 9415013 A FR9415013 A FR 9415013A FR 9415013 A FR9415013 A FR 9415013A FR 2728088 A1 FR2728088 A1 FR 2728088A1
- Authority
- FR
- France
- Prior art keywords
- server
- file
- emulated
- resource
- station
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/10—File systems; File servers
Abstract
Le procédé d'échange d'informations en mode client-serveur entre stations reliées par un réseau de communication consiste, - à 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 fichiers-ressource au niveau du coupleur (8) entre la station (4) et le réseau: - à utiliser le mécanisme d'interception (INT) des requêtes de consultation de fichier-ressource, en les re-dirigeant vers le serveur local émulé (SEM); et - à faire jouer au serveur émulé (SEM) le rôle, soit d'antémémoire pour réduire le trafic, soit de commutateur pour pallier la panne d'un serveur.
Description
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.
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.
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é.
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.
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.
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.
Claims (5)
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.
Priority Applications (4)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR9415013A FR2728088A1 (fr) | 1994-12-13 | 1994-12-13 | Procede d'echange d'informations en mode client/serveur, entre stations reliees par un reseau de communication |
| US08/849,855 US5996017A (en) | 1994-12-13 | 1995-12-07 | Method for information exchange in the customer/server mode between stations connected by a communication network |
| PCT/FR1995/001623 WO1996018959A1 (fr) | 1994-12-13 | 1995-12-07 | Procede d'echange d'informations en mode client/serveur, entre stations reliees par un reseau de communication |
| AU43492/96A AU4349296A (en) | 1994-12-13 | 1995-12-07 | Method for information exchange in the customer/server mode between stations connected by a communication network |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR9415013A FR2728088A1 (fr) | 1994-12-13 | 1994-12-13 | Procede d'echange d'informations en mode client/serveur, entre stations reliees par un reseau de communication |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| FR2728088A1 true FR2728088A1 (fr) | 1996-06-14 |
| FR2728088B1 FR2728088B1 (fr) | 1997-03-07 |
Family
ID=9469769
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| FR9415013A Granted FR2728088A1 (fr) | 1994-12-13 | 1994-12-13 | Procede d'echange d'informations en mode client/serveur, entre stations reliees par un reseau de communication |
Country Status (4)
| Country | Link |
|---|---|
| US (1) | US5996017A (fr) |
| AU (1) | AU4349296A (fr) |
| FR (1) | FR2728088A1 (fr) |
| WO (1) | WO1996018959A1 (fr) |
Families Citing this family (9)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7003719B1 (en) * | 1999-01-25 | 2006-02-21 | West Publishing Company, Dba West Group | System, method, and software for inserting hyperlinks into documents |
| US8600783B2 (en) | 2000-08-18 | 2013-12-03 | The Crawford Group, Inc. | Business to business computer system for communicating and processing rental car reservations using web services |
| US7899690B1 (en) | 2000-08-18 | 2011-03-01 | The Crawford Group, Inc. | Extended web enabled business to business computer system for rental vehicle services |
| US6810430B1 (en) * | 2000-09-29 | 2004-10-26 | Abb Automation Inc. | Network communications coupler |
| US7333966B2 (en) | 2001-12-21 | 2008-02-19 | Thomson Global Resources | Systems, methods, and software for hyperlinking names |
| US8447963B2 (en) | 2002-06-12 | 2013-05-21 | Bladelogic Inc. | Method and system for simplifying distributed server management |
| US20040039612A1 (en) | 2002-06-14 | 2004-02-26 | Neil Fitzgerald | Method and apparatus for customer direct on-line reservation of rental vehicles |
| US8108231B2 (en) | 2002-06-14 | 2012-01-31 | The Crawford Group, Inc. | Method and apparatus for improved customer direct on-line reservation of rental vehicles |
| US8271309B2 (en) | 2006-03-16 | 2012-09-18 | The Crawford Group, Inc. | Method and system for providing and administering online rental vehicle reservation booking services |
Citations (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| EP0566895A2 (fr) * | 1992-04-20 | 1993-10-27 | International Business Machines Corporation | Gestionnaire de fichiers pour des fichiers partagés par des clients hétérogènes |
Family Cites Families (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5426747A (en) * | 1991-03-22 | 1995-06-20 | Object Design, Inc. | Method and apparatus for virtual memory mapping and transaction management in an object-oriented database system |
| US5615373A (en) * | 1993-08-26 | 1997-03-25 | International Business Machines Corporation | Data lock management in a distributed file server system determines variable lock lifetime in response to request to access data object |
| US5740231A (en) * | 1994-09-16 | 1998-04-14 | Octel Communications Corporation | Network-based multimedia communications and directory system and method of operation |
| US5600644A (en) * | 1995-03-10 | 1997-02-04 | At&T | Method and apparatus for interconnecting LANs |
-
1994
- 1994-12-13 FR FR9415013A patent/FR2728088A1/fr active Granted
-
1995
- 1995-12-07 WO PCT/FR1995/001623 patent/WO1996018959A1/fr active Application Filing
- 1995-12-07 AU AU43492/96A patent/AU4349296A/en not_active Abandoned
- 1995-12-07 US US08/849,855 patent/US5996017A/en not_active Expired - Fee Related
Patent Citations (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| EP0566895A2 (fr) * | 1992-04-20 | 1993-10-27 | International Business Machines Corporation | Gestionnaire de fichiers pour des fichiers partagés par des clients hétérogènes |
Non-Patent Citations (2)
| Title |
|---|
| ALONSO R ET AL: "USING STASHING TO INCREASE NODE AUTONOMY IN DISTRIBUTED FILE SYSTEMS", PROCEEDINGS OF THE SYMPOSIUM ON RELIABLE DISTRIBUTED SYSTEMS, HUNTSVILLE, OCT. 9 - 11, 1990, no. SYMP. 9, 9 October 1990 (1990-10-09), INSTITUTE OF ELECTRICAL AND ELECTRONICS ENGINEERS, pages 12 - 21, XP000278455 * |
| LISKOV B ET AL: "A REPLICATED UNIX FILE SYSTEM", OPERATING SYSTEMS REVIEW (SIGOPS), vol. 25, no. 1, 1 January 1991 (1991-01-01), pages 60 - 64, XP000293500 * |
Also Published As
| Publication number | Publication date |
|---|---|
| FR2728088B1 (fr) | 1997-03-07 |
| US5996017A (en) | 1999-11-30 |
| AU4349296A (en) | 1996-07-03 |
| WO1996018959A1 (fr) | 1996-06-20 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP4284190B2 (ja) | 管理対象オブジェクトの複写および配信 | |
| US8914429B2 (en) | Method for creating global distributed namespace | |
| US9009270B2 (en) | Scalable, high performance and highly available distributed storage system for internet content | |
| US7272613B2 (en) | Method and system for managing distributed content and related metadata | |
| CN100525288C (zh) | 网络中大有效负载分布的方法和装置 | |
| AU2009268792B2 (en) | Media delivery in data forwarding storage network | |
| US7970856B2 (en) | System and method for managing and distributing assets over a network | |
| EP2000929B1 (fr) | Utilisation d'un arbre de hachage à préfixes (PHT) pour la localisation des services au sein d'un réseau de communication poste-à-poste | |
| CA2738641C (fr) | Chiffrement par rotation lors du stockage pour le transfert de donnees | |
| CN104601724B (zh) | 上传和下载文件的方法及系统 | |
| CN101257396A (zh) | 一种基于p2p技术的多域内容分发系统及相应的方法 | |
| US20110179131A1 (en) | Media delivery in data forwarding storage network | |
| FR2870022A1 (fr) | Procede et dispositif de distribution de donnees numeriques notamment pour reseau pair-a-pair | |
| FR2728088A1 (fr) | Procede d'echange d'informations en mode client/serveur, entre stations reliees par un reseau de communication | |
| CN101841540A (zh) | 一种基于Hash函数算法发布多媒体内容的方法 | |
| WO2010076536A2 (fr) | Procède de traitement de requêtes émises par un client | |
| WO2020233765A2 (fr) | Système de stockage distribué dans le fog computing | |
| JP3571862B2 (ja) | 情報受配信システム | |
| WO2005099411A2 (fr) | Systeme et procede de mise en cache de messages electroniques | |
| WO2014135766A1 (fr) | Procédé de traitement dans un réseau centré sur les contenus d'une demande relative a un segment de données | |
| FR3024315A1 (fr) | Systeme et procede de mise a disposition de fichiers informatiques. | |
| FR2877529A1 (fr) | Procede d'acces commun par partage a des donnees temoins volumineuses sur des sites web independants appartenant a un domaine distinct et serveur http permettant la mise en oeuvre du procede. | |
| FR2824214A1 (fr) | Serveur perfectionne de gestion de donnees entre un reseau et des terminaux d'utilisateur, et dispositif et procede de traitement de donnees associes |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| ST | Notification of lapse |