+

WO1996018959A1 - 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 PDF

Info

Publication number
WO1996018959A1
WO1996018959A1 PCT/FR1995/001623 FR9501623W WO9618959A1 WO 1996018959 A1 WO1996018959 A1 WO 1996018959A1 FR 9501623 W FR9501623 W FR 9501623W WO 9618959 A1 WO9618959 A1 WO 9618959A1
Authority
WO
WIPO (PCT)
Prior art keywords
server
file
emulated
resource
station
Prior art date
Application number
PCT/FR1995/001623
Other languages
English (en)
Inventor
Patrick Cipiere
Original Assignee
Inria Institut National De Recherche En Informatique Et En Automatique
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Inria Institut National De Recherche En Informatique Et En Automatique filed Critical Inria Institut National De Recherche En Informatique Et En Automatique
Priority to AU43492/96A priority Critical patent/AU4349296A/en
Priority to US08/849,855 priority patent/US5996017A/en
Publication of WO1996018959A1 publication Critical patent/WO1996018959A1/fr

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

Definitions

  • the present invention relates to the technical field of information exchange in client-server mode, between stations connected by a communication network.
  • a network is provided formed of a communication medium, and of a plurality of stations each associated with a coupler on said medium,
  • At least one server station is provided in this network
  • each coupler is provided with a network communication protocol, allowing the processing of resource file consultation requests between some of the stations known as client stations and the server station.
  • a server allows access to files for clients who request it.
  • the server is a machine that stores a large number of files in a single and central way to reduce implementation costs (a single memory) and simplify file administration (a single area to update).
  • NFS Network File System
  • SUN MICROSYSTEMS INC
  • server offers for sharing for its customers a plurality of files arranged according to a file structure chosen.
  • the file tree structure is built from the unequivocal identification of each file by a label, also called "file handle”. This identification is carried out by the server.
  • a client who wishes to access a tree file must first request the label of the root of this tree (root file handle).
  • the server does not keep track of the distribution of files (information and data) to the destination of clients (stateless). Under these conditions, it cannot warn clients when changes are made to files at the server level. As a result, clients regularly poll the server to verify that the data and information they have in memory is up to date.
  • the invention aims to provide a solution to these problems without destroying the interoperability of the communication protocol.
  • Another object of the invention aims to provide an easy and simple implementation method, requiring no modification of the existing software layers managing the communication protocol, in particular the NFS protocol.
  • d2 provide an emulated server suitable for dialog according to said protocol to process requests for consulting a resource file
  • d3 at the coupler between the station and the network, provide a mechanism for intercepting requests for consulting a resource file, by redirecting them to the local emulated server,
  • Such a method has the advantage of generally protecting clients against a server failure in a client / server environment while retaining the interoperability of the communication protocol.
  • iii) define the key condition for the use of the substitute location of a resource file according to the availability and obsolescence of said resource file
  • the emulated server plays the role of cache memory so as to improve the performance of the network by reducing the number of requests to the server.
  • the auxiliary file here acts as a synchronization file to identify any modification made to the server-side files, and update the files stored in the emulated server.
  • iii) define the key condition for using the substitute location of a resource file according to the absence / presence of a correspondence between the substitute location and the designation of the resource file
  • iv maintain the auxiliary file at the level of the emulated server, according to any modification made to the correspondence between the substitute location and the designation of each resource file.
  • the emulated server plays the role of switch by directing the file consultation request to an available server, which improves the reliability of the network.
  • the auxiliary file here acts as a correspondence tree to direct any file consultation request to an available server.
  • FIG. 1 is a block diagram illustrating the communication network in which the method according to the invention is implemented
  • FIG. 2 is a flowchart illustrating the steps of the client-side process, in the context where the emulated server plays the role of cache memory;
  • FIG. 3 is a flowchart illustrating the steps relating to the validation of the cache memory according to the state of the auxiliary file according to the invention.
  • FIG. 4 is a flowchart illustrating, the steps relating to the operation of the emulated server playing the role of switch according to the invention.
  • the device in which the method of the invention is implemented is represented in FIG. 1. It is a network formed by a communication medium 2, for example of the ETHERNET type (Registered trademark) and of a plurality of stations 4, 6 each associated with a coupler 8 on said medium 2.
  • station 6 is here a server station.
  • Each coupler 8 is provided with a network communication protocol allowing the processing of resource file consultation request between some of the stations called client-stations and the server station.
  • Each station 4, 6 for communicating in a client / server environment includes software layers 10 of the IP type for "INTERNET PROTOCOL", and 12 of the TCP / UDP type for "Transmission Control Protocol / User Datagram Protocol”.
  • the client station 4 includes a mass memory (not shown) of the order of 500 megabytes.
  • the server station includes a mass memory of the order of 8 Gigabytes.
  • RAMs (not shown) of 6 to 32 megabytes are also provided at each station.
  • the server allows access to files stored in the server's mass memory and waits for REQ requests from clients.
  • the server processes these REQ requests and send the RES response to the clients by passing through the communication medium 2.
  • ECH data exchanges are provided for setting up and operating the client / server mode.
  • the couplers are used to route messages from clients to servers and vice versa.
  • the method according to the invention finds a particular application in the communication protocol, called NFS and in which the server offers for sharing for its customers a plurality of files arranged according to a conventional file tree structure in a computer environment articulated around a root and branch directories.
  • the file tree structure is built from the unequivocal identification of each file by a label, also called "file handle”. This identification is carried out by the server.
  • the mechanisms for creating this label are specific to the server. It is therefore very difficult for another machine to reliably generate labels identical to those of the server.
  • a client who wishes to access a file in the tree structure offered by the server must first obtain the file handle from the root of this tree structure: the root file handle.
  • the request to obtain this root file handle has the particularity of being the only one not to rely on another file handle. All other requests are made on the basis of a file handle obtained during a previous request.
  • the first category of requests is the one called "look up" which allows to request the file handle of a file whose name is known and the file handle of the directory which contains. It is this request which makes it possible to apprehend the tree structure.
  • the second category of requests is the one called "readlink" which allows to request the name of the link contained in a file of which we know the file handle.
  • the third category of requests is the one called “Statat" which allows to request the status information or attributes of a file for which we know the file handle.
  • the fourth category of requests is the one called "read” which allows you to request a data block from a file for which we know the file handle.
  • the server does not keep track of the distribution of files (information and data) to the clients' destination. Under these conditions, it cannot warn clients when changes are made to files stored at the server level. As a result, clients regularly poll the server to verify that the data and information they have in memory is up to date.
  • the NFS service or protocol does not provide a mechanism to protect the client from such incidents, such as a server failure.
  • the method according to the invention makes it possible to solve these problems while retaining the interoperability of the NFS protocol.
  • i number integer adjustable and limited in practice to a few thousand.
  • the emulated server has a cache memory with a capacity of the order of 128 kilobytes, adjustable according to the applications.
  • the REQ consultation requests are intercepted using the INT mechanism, for example of the LOOP BACK type available in the IP protocol. Only "look up, read link and getattr" requests are likely to be intercepted. The other requests are transmitted directly to the remote server.
  • the INT mechanism for example of the LOOP BACK type available in the IP protocol. Only "look up, read link and getattr" requests are likely to be intercepted. The other requests are transmitted directly to the remote server.
  • step 120 at the emulated server, we receive the intercepted request and we access the auxiliary file.
  • the request is processed with the substitute location ESi (step 140) , i.e. the RES response is given by the local emulated server.
  • step 150 the request is transmitted to the remote server whose RES response (step 160) is recorded (step 170) in the cache of the emulated server.
  • the desired file is stored in the substitute location ESi of the emulated server. Otherwise, information relating to this absence of the file Fi in the remote server is stored in the emulated server.
  • auxiliary file representative of a correspondence between a designation of a resource file and, on the one hand a substitute location ESi thereof, on the other hand a key condition for the use of this substitute location.
  • the key condition for using the substitute location of a resource file is the availability and 1 "obsolescence of said file.
  • data exchanges are planned on the network on the initiative of the client station for the consultation of the auxiliary file of the server station and for updating the substitute locations of the emulated server or servers. depending on the state of said auxiliary file.
  • step relating to the maintenance of the auxiliary file comprises the following steps (FIG. 3):
  • step 200 at the emulated server level (step 200), after a predetermined time delay or a predetermined event, generate a request to consult the auxiliary file for the remote server (step 210);
  • step 220 receiving the request to consult the auxiliary file and delivering a response representative of the state of the auxiliary file with respect to its state during the previous request to consult the auxiliary file (step 220);
  • step 250 receiving the request to update the content of the cache of the emulated server and transmitting the content of resource files to the emulated server
  • the state of the auxiliary file is requested periodically (adjustable periodicity, in practice every 128 requests or every 30 seconds of activity) by the local emulated server to the remote server by, for example a request of the getattr type. If the state of this auxiliary file changes, the cache memory is deemed to be empty and the process of storing in the cache memory begins.
  • FIG. 4 there is shown a flowchart which illustrates the method according to the invention in which the emulated server plays the role of switch.
  • the emulated server is capable, in case of non-response from the remote server to which it has just addressed, to submit the same request to another server. This is made possible according to the invention by the fact that the labels your distributed by the local server are completely independent from the remote server.
  • the local emulated server keeps a correspondence table between the labels it distributes and those actually supplied by the servers. This table is dynamically built according to the look up requests generated by the client.
  • At least one other server station is provided, and in this station, it is planned to store at least part of the resource files in their respective substitute location according to the tree structure chosen.
  • the key condition for using the substitute location of a resource file is defined according to the establishment of a correspondence between said substitute location and the designation of the resource file.
  • an auxiliary file is maintained at the level of the emulated server, as a function of any modification made to said correspondence between the substitute location and the designation of the resource file.
  • auxiliary file is here maintained at the level of the emulated server, while it is maintained at the level of the remote server when the emulated server plays the role of cache memory.
  • step 300 provision is made to generate a file consultation request intended for the server remote (step 310); - At the remote server, it is planned to receive the consultation request and to consult the new correspondence between the substitute location and the designation of the resource file. This new correspondence is obtained through the designation of the resource file accompanying the consultation request. The new correspondence is then transmitted to the emulated server (step 320):
  • the new correspondence is received and recorded (step 330), and in the request for consulting the file, the old correspondence is replaced by the new correspondence (step 340).

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Data Mining & Analysis (AREA)
  • Databases & Information Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

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 fichier-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.
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 consulta¬ tion de fichier-ressource entre certaines des stations dites stations-client et la station-serveur.
D'une 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éve¬ loppé 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 façon univoque de chaque fichier par une étiquette, appelée encore "file handle". Cette identification est réalisée par le serveur. En prati¬ que, un client qui souhaite accéder à un fichier de l'arbo¬ rescence 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.
Il 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.
Il est à remarquer que dans la majorité des cas, le redémar- rage 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. Il 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 protoco¬ le.
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 modifica- tion 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 d'une correspondance entre une désignation d'un fichier- ressource 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 consulta¬ tion de fichier-ressource, en les re-dirigeant vers le serveur local émulé,
d4) au niveau du serveur émulé, accéder au fichier auxiliai- re, 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. 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éra¬ bilité 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 fichiers- ressource 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 station- serveur, 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'ini¬ tiative 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.
Il 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 synchroni¬ sation 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 suivan¬ tes :
i) au niveau de la station-serveur, rangés les fichiers- ressource selon une arborescence choisie,
ii) prévoir au moins une station-serveur supplémentaire et stocker dans celle-ci, une partie au moins des fichiers- ressource dans leur emplacement-substitut respectif selon 1'arborescence choisie,
iii) définir la condition-clef pour le recours à l'emplace¬ ment-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ésigna¬ tion de chaque fichier-ressource.
Il 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 ci- aprè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 lé 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. Il 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 sta¬ tions-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. Il 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.
Il 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.
Il est à remarquer que dans la majorité des cas, le redémar- rage 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. Il 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 proto¬ cole 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 emplace¬ ment-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 consulta¬ tion 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'emplacement- substitut 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 informa- tion relative à cette absence du fichier Fi dans le serveur distant.
Il 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 1"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 consulta¬ tion 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 tempori¬ sation prédéterminée ou un événement prédéterminé, générer une requête de consultation du fichier auxiliaire à destina- tion 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 fichiers- ressource (é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.
Il 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épen¬ dantes 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 station- serveur, et dans celle-ci, il est prévu de stocker une partie au moins des fichiers-ressource dans leur emplacement- substitut respectif selon l'arborescence choisie.
On définit la condition clé pour le recours à l'emplacement- 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.
Il 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 correspon- dance 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 corres¬ pondance 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 enregis- tre 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).
Il est à remarquer que les deux fonctionnalités antémémoire et commutateur décrites ci-avant sont totalement indépendan¬ tes l'une 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.
D'une 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'exploita¬ tion, 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

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 communica- tion 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 fichier- ressource 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 re¬ dirigeant 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 fichiers- ressource (Fi) selon une arborescence choisie,
ii) au niveau du serveur émulé (SEM), stocker une partie au moins des fichiers-ressource (Fi) dans leur emplacement- substitut respectif (ESi) formant antémémoire,
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 station- serveur, 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'ini¬ tiative 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 auxi- liaire par rapport à son état précédent, invalider la totalité de l'antémémoire 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
v5) 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 fichiers- ressource selon une arborescence choisie,
2) prévoir au moins une autre station-serveur et dans celle- ci, 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'emplacement- substitut d'un fichier-ressource selon l'établissement d'une correspondance entre l'emplacement-substitut et la désigna¬ tion du fichier-ressource, et
4) entretenir le fichier auxiliaire au niveau du serveur émulé, en fonction de toute modification apportée à ladite correspondance entre l'emplacement-substitut et la désigna¬ tion 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 correspon¬ dance 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-ressour¬ ce, 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 fichier- ressource, et remplacer dans la requête de consultation de fichier, l'ancienne correspondance par la nouvelle correspon¬ dance.
PCT/FR1995/001623 1994-12-13 1995-12-07 Procede d'echange d'informations en mode client/serveur, entre stations reliees par un reseau de communication WO1996018959A1 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
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
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

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR94/15013 1994-12-13
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 (1)

Publication Number Publication Date
WO1996018959A1 true WO1996018959A1 (fr) 1996-06-20

Family

ID=9469769

Family Applications (1)

Application Number Title Priority Date Filing Date
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

Country Status (4)

Country Link
US (1) US5996017A (fr)
AU (1) AU4349296A (fr)
FR (1) FR2728088A1 (fr)
WO (1) WO1996018959A1 (fr)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2000043918A3 (fr) * 1999-01-25 2000-12-28 West Publishing Company D B A Systeme permettant d'introduire des hyperliens dans des documents
US7333966B2 (en) 2001-12-21 2008-02-19 Thomson Global Resources Systems, methods, and software for hyperlinking names
US7571174B2 (en) 2003-12-31 2009-08-04 Thomson Reuters Global Resurces Systems, methods, interfaces and software for automated collection and integration of entity data into online databases and professional directories

Families Citing this family (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
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
US7275038B1 (en) 2000-08-18 2007-09-25 The Crawford Group, Inc. Web enabled business to business operating system for rental car services
US6810430B1 (en) * 2000-09-29 2004-10-26 Abb Automation Inc. Network communications coupler
US8447963B2 (en) 2002-06-12 2013-05-21 Bladelogic Inc. Method and system for simplifying distributed server management
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
US20040039612A1 (en) 2002-06-14 2004-02-26 Neil Fitzgerald Method and apparatus for 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
US12012110B1 (en) 2023-10-20 2024-06-18 Crawford Group, Inc. Systems and methods for intelligently transforming data to generate improved output data using a probabilistic multi-application network

Citations (1)

* Cited by examiner, † Cited by third party
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)

* Cited by examiner, † Cited by third party
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

Patent Citations (1)

* Cited by examiner, † Cited by third party
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)

* Cited by examiner, † Cited by third party
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 *

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2000043918A3 (fr) * 1999-01-25 2000-12-28 West Publishing Company D B A Systeme permettant d'introduire des hyperliens dans des documents
US7003719B1 (en) 1999-01-25 2006-02-21 West Publishing Company, Dba West Group System, method, and software for inserting hyperlinks into documents
US7333966B2 (en) 2001-12-21 2008-02-19 Thomson Global Resources Systems, methods, and software for hyperlinking names
US9002764B2 (en) 2001-12-21 2015-04-07 Thomson Reuters Global Resources Systems, methods, and software for hyperlinking names
US7571174B2 (en) 2003-12-31 2009-08-04 Thomson Reuters Global Resurces Systems, methods, interfaces and software for automated collection and integration of entity data into online databases and professional directories

Also Published As

Publication number Publication date
FR2728088A1 (fr) 1996-06-14
US5996017A (en) 1999-11-30
AU4349296A (en) 1996-07-03
FR2728088B1 (fr) 1997-03-07

Similar Documents

Publication Publication Date Title
CN104615666B (zh) 有助于减少网络通信的客户端和服务器
US8914429B2 (en) Method for creating global distributed namespace
EP1320994B1 (fr) Systemes et procedes d'interaction avec les utilisateurs dans un reseau de communication
JP4284190B2 (ja) 管理対象オブジェクトの複写および配信
KR101424362B1 (ko) 컨텐츠 전송 네트워크를 통한 청크식 다운로드
AU2009268792B2 (en) Media delivery in data forwarding storage network
US6167438A (en) Method and system for distributed caching, prefetching and replication
US8447842B2 (en) Scalable, high performance and highly available distributed storage system for internet content
CN100525288C (zh) 网络中大有效负载分布的方法和装置
US6253234B1 (en) Shared web page caching at browsers for an intranet
US7970856B2 (en) System and method for managing and distributing assets over a network
US20020133491A1 (en) Method and system for managing distributed content and related metadata
US20050198238A1 (en) Method and apparatus for initializing a new node in a network
AU2009296490B2 (en) Rotating encryption in data forwarding storage
US8599678B2 (en) Media delivery in data forwarding storage network
CN104601724B (zh) 上传和下载文件的方法及系统
EP2113150A2 (fr) Distribution améliorée de contenu sur un réseau
FR2917259A1 (fr) Utilisation d'un arbre de hachage a prefixes (pht) pour la localisation des services au sein d'un reseau de communication poste-a-poste
US20080178094A1 (en) Server-Side Peer-to-Peer (P2P) Media Streaming
JP6485980B2 (ja) ネットワークアドレスの解決
WO1996018959A1 (fr) Procede d'echange d'informations en mode client/serveur, entre stations reliees par un reseau de communication
FR2869133A1 (fr) Systeme et procede de tracabilite de contenus electroniques syndiques via un reseau de communication de type internet
US20060168145A1 (en) Method for creating a secure and reliable content distribution framework
WO2019074546A1 (fr) Transfert d'informations dans un nom d'hôte dans un réseau de distribution de contenu (cdn)
JP3571862B2 (ja) 情報受配信システム

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AU CA JP KR MX US

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): AT BE CH DE DK ES FR GB GR IE IT LU MC NL PT SE

DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
121 Ep: the epo has been informed by wipo that ep was designated in this application
WWE Wipo information: entry into national phase

Ref document number: 08849855

Country of ref document: US

122 Ep: pct application non-entry in european phase
NENP Non-entry into the national phase

Ref country code: CA

点击 这是indexloc提供的php浏览器服务，不要输入任何密码和下载