CA2137620C - Procede de simulation d'une architecture "serveur" a partir d'une architecture "client" - Google Patents
Procede de simulation d'une architecture "serveur" a partir d'une architecture "client"Info
- Publication number
- CA2137620C CA2137620C CA002137620A CA2137620A CA2137620C CA 2137620 C CA2137620 C CA 2137620C CA 002137620 A CA002137620 A CA 002137620A CA 2137620 A CA2137620 A CA 2137620A CA 2137620 C CA2137620 C CA 2137620C
- Authority
- CA
- Canada
- Prior art keywords
- machine
- rpc
- call
- function
- relay
- 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.)
- Expired - Fee Related
Links
- 238000000034 method Methods 0.000 title claims abstract description 44
- 230000008569 process Effects 0.000 title description 5
- 238000004891 communication Methods 0.000 claims abstract description 20
- 230000006870 function Effects 0.000 claims description 57
- 238000004088 simulation Methods 0.000 claims description 14
- 230000007246 mechanism Effects 0.000 claims description 7
- 230000000903 blocking effect Effects 0.000 claims description 5
- 230000003213 activating effect Effects 0.000 claims 1
- 102100029143 RNA 3'-terminal phosphate cyclase Human genes 0.000 description 35
- 101100252610 Neurospora crassa (strain ATCC 24698 / 74-OR23-1A / CBS 708.71 / DSM 1257 / FGSC 987) rpc-82 gene Proteins 0.000 description 2
- 230000000694 effects Effects 0.000 description 2
- 101000689002 Homo sapiens DNA-directed RNA polymerase III subunit RPC1 Proteins 0.000 description 1
- 238000006243 chemical reaction Methods 0.000 description 1
- 238000005094 computer simulation Methods 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
Classifications
-
- B—PERFORMING OPERATIONS; TRANSPORTING
- B01—PHYSICAL OR CHEMICAL PROCESSES OR APPARATUS IN GENERAL
- B01D—SEPARATION
- B01D33/00—Filters with filtering elements which move during the filtering operation
- B01D33/044—Filters with filtering elements which move during the filtering operation with filtering bands or the like supported on cylinders which are pervious for filtering
- B01D33/048—Filters with filtering elements which move during the filtering operation with filtering bands or the like supported on cylinders which are pervious for filtering with endless filtering bands
-
- B—PERFORMING OPERATIONS; TRANSPORTING
- B01—PHYSICAL OR CHEMICAL PROCESSES OR APPARATUS IN GENERAL
- B01D—SEPARATION
- B01D33/00—Filters with filtering elements which move during the filtering operation
- B01D33/056—Construction of filtering bands or supporting belts, e.g. devices for centering, mounting or sealing the filtering bands or the supporting belts
-
- B—PERFORMING OPERATIONS; TRANSPORTING
- B01—PHYSICAL OR CHEMICAL PROCESSES OR APPARATUS IN GENERAL
- B01D—SEPARATION
- B01D33/00—Filters with filtering elements which move during the filtering operation
- B01D33/44—Regenerating the filter material in the filter
- B01D33/46—Regenerating the filter material in the filter by scrapers, brushes nozzles or the like acting on the cake-side of the filtering element
- B01D33/466—Regenerating the filter material in the filter by scrapers, brushes nozzles or the like acting on the cake-side of the filtering element scrapers
-
- B—PERFORMING OPERATIONS; TRANSPORTING
- B01—PHYSICAL OR CHEMICAL PROCESSES OR APPARATUS IN GENERAL
- B01D—SEPARATION
- B01D33/00—Filters with filtering elements which move during the filtering operation
- B01D33/44—Regenerating the filter material in the filter
- B01D33/48—Regenerating the filter material in the filter by flushing, e.g. counter-current air-bumps
- B01D33/50—Regenerating the filter material in the filter by flushing, e.g. counter-current air-bumps with backwash arms, shoes or nozzles
-
- B—PERFORMING OPERATIONS; TRANSPORTING
- B01—PHYSICAL OR CHEMICAL PROCESSES OR APPARATUS IN GENERAL
- B01D—SEPARATION
- B01D33/00—Filters with filtering elements which move during the filtering operation
- B01D33/58—Handling the filter cake in the filter for purposes other than for regenerating the filter cake remaining on the filtering element
- B01D33/68—Retarding cake deposition on the filter during the filtration period, e.g. using stirrers
Landscapes
- Chemical & Material Sciences (AREA)
- Chemical Kinetics & Catalysis (AREA)
- Computer And Data Communications (AREA)
- Filtration Of Liquid (AREA)
- Communication Control (AREA)
Abstract
L'invention concerne un procédé de simulation, dans un réseau, d'une architecture "serveur" à partir d'une architecture "client" d'une première machine (PS) pour l'exécution d'appels de procédure à distance RPC émis par au moins une machine d'architecture "client" (CL). Selon ce procédé la première machine (PS) émet préalablement un appel RPC vers une troisième machine d'architecture "serveur" (RE) utilisée comme machine relais entre la première (PS) et la deuxième (CL) machines, cet appel RPC ouvrant un contexte de communication pour la suite des échanges alors que la première machine (PS) se bloque dans l'attente d'un retour de l'appel RPC. Lorsque la seconde machine (CL) émet un appel RPC représentatif d'une fonction déterminée à exécuter par la première machine (PS), cet appel est transmis vers la machine relais (RE) qui après reconnaissance de la fonction le retransmet vers la première machine (PS) par retour de l'appel RPC bloqué. La première machine (PS) demande alors les paramètres d'entrée de la fonction à exécuter connus de la machine relais (RE) puis exécute la fonction dès leur réception en fournissant comme paramètre de sortie le résultat à la seconde machine (CL) via la machine relais (RE).
Description
~~ )~~3~~
Procédé de simulation d'une architecture "serveur" à partir d'une architecture "client".
La présente invention concerne un procédé de simulation) dans un réseau) s d'une architecture "serveur" à partir d'une architecture "client" d'une première machine pour l'exécution d'appels de procédure à distance RPC
(Remote Procedure Call) émis par au moins une seconde machine d'architecture "client".
io De manière générale) le service d'appels de procédure à distance RPC
fournit un langage de niveau élevé et permet aux programmes exécutés localement d'appeler des procédures installées sur des systèmes à
distance. Ce service constitue un élément fondamental du modèle "client-serveur". Ce modèle est un modèle informatique asymétrique constitué de is deux unités séparées et logiques travaillant en coopération. Une machine d'architecture "client", communément appelée "client", demande des informations ou des actions qu'une machine d'architecture "serveur" peut exécuter plus spécifiquement ou dans de meilleures conditions. La machine d'architecture "serveur") communément appelée "serveur", répond aux Zo demandes du "client" et exécute des tâches lourdes ou spécialisées.
Dans ce contexte) il peut étre ressenti le besoin d'utiliser une machine d'architecture exclusivement "client" comme "serveur". La solution à ce problème consistait) jusqu'à présent) à porter une partie "serveur" sur la Zs machine "client", c'est-à-dire à reproduire l'intégralité du code source d'une partie "serveur". Une telle solution est longue et fastidieuse et par conséquent co0teuse et ceci d'autant plus que plusieurs versions peuvent se succéder à brève échéance et que de plus le code peut étre malaisé à
porter sur des systèmes propriétaires.
La présente invention a pour but de remédier aux inconvénients précités et propose un procédé de simulation d'une architecture "serveur" à partir d'une architecture "client" qui ne nécessite pas une recopie d'une partie "serveur" et qui par conséquent est peu onéreux et rapide à mettre en 3s oeuvre.
Pour cela le procédé de simulation mentionné dans le préambule est remarquable en ce que la première machine émet préalablement un appel 213~~?(~
Procédé de simulation d'une architecture "serveur" à partir d'une architecture "client".
La présente invention concerne un procédé de simulation) dans un réseau) s d'une architecture "serveur" à partir d'une architecture "client" d'une première machine pour l'exécution d'appels de procédure à distance RPC
(Remote Procedure Call) émis par au moins une seconde machine d'architecture "client".
io De manière générale) le service d'appels de procédure à distance RPC
fournit un langage de niveau élevé et permet aux programmes exécutés localement d'appeler des procédures installées sur des systèmes à
distance. Ce service constitue un élément fondamental du modèle "client-serveur". Ce modèle est un modèle informatique asymétrique constitué de is deux unités séparées et logiques travaillant en coopération. Une machine d'architecture "client", communément appelée "client", demande des informations ou des actions qu'une machine d'architecture "serveur" peut exécuter plus spécifiquement ou dans de meilleures conditions. La machine d'architecture "serveur") communément appelée "serveur", répond aux Zo demandes du "client" et exécute des tâches lourdes ou spécialisées.
Dans ce contexte) il peut étre ressenti le besoin d'utiliser une machine d'architecture exclusivement "client" comme "serveur". La solution à ce problème consistait) jusqu'à présent) à porter une partie "serveur" sur la Zs machine "client", c'est-à-dire à reproduire l'intégralité du code source d'une partie "serveur". Une telle solution est longue et fastidieuse et par conséquent co0teuse et ceci d'autant plus que plusieurs versions peuvent se succéder à brève échéance et que de plus le code peut étre malaisé à
porter sur des systèmes propriétaires.
La présente invention a pour but de remédier aux inconvénients précités et propose un procédé de simulation d'une architecture "serveur" à partir d'une architecture "client" qui ne nécessite pas une recopie d'une partie "serveur" et qui par conséquent est peu onéreux et rapide à mettre en 3s oeuvre.
Pour cela le procédé de simulation mentionné dans le préambule est remarquable en ce que la première machine émet préalablement un appel 213~~?(~
2 RPC vers une troisième machine d'architecture "serveur" utilisée entre la première et la deuxième machines et pour cela appelée machine relais, cet appel RPC ouvrant un contexte de communication (appelé "client context"
par l'homme du métier dans un environnement d'information répartie et s selon la sémantique de DCE, DCE (Distributed Computing Environment) étant une marque déposée par Open Software Foundation) pour la suite des échanges alors que ladite première machine se bloque sur ledit appel dans l'attente de son retour, puis lorsque la seconde machine émet un appel RPC représentatif d'une fonction déterminée à exécuter par la io première machine) cet appel est transmis vers la machine relais qui après reconnaissance de la fonction à exécuter fe retransmet vers la première machine par retour de l'appel RPC bloqué, la première machine demandant alors les paramètres d'entrée de la fonction à exécuter présents dans la machine relais puis exécutant ladite fonction après réception desdits is paramètres d'entrée et enfin fournissant, comme paramètre de sortie, le résultat à la seconde machine via la machine relais.
Ainsi grâce au procédé de simulation selon l'invention, dans un réseau, une machine "client" peut lancer des appels de procédure RPC vers une autre Zo machine "client" utilisée comme "serveur' ("pseudo-serveur' et ceci sans modification ou recopie du code source d'une partie "serveur"; le code "client" est standard, il suffit pour cela de sélectionner un "serveur" du réseau qui servira alors de machine relais et autorisera le dialogue entre la machine "client" et fe "pseudo-serveur". En effet, ta machine "client" voit Zs alors le couple "senreur"P'pseudo-serveur" comme une machine "serveur"
homogène. Dans ces conditions tout appel RPC avec tout type de paramètre peut être exécuté. En outre, de manière générale fintertace de la procédure est décrite dans un langage de description d'intertace (IDL).
Cette interface est compilée en deux talons (appelés "stubs" par l'homme 3o du métier), un pour le cSté "client", l'autre pour le c8té "serveur" du RPC, les talons étant compilés avec les programmes "client" et "serveur"
respectivement pour donner les deux exécutables "client" et "serveur". Le talon "client" est une fonction dont l'interface respecte fintertace décrite en IDL et qui a pour but de transformer les paramètres d'appel de la ss représentation propre à la machine "client" en une représentation universelle dite représentation de réseau. Le but du talon "serveur" est de transformer les paramètres d'appel de la représentation réseau en la représentation propre à la machine senneur et d'appeler ensuite la fonction
par l'homme du métier dans un environnement d'information répartie et s selon la sémantique de DCE, DCE (Distributed Computing Environment) étant une marque déposée par Open Software Foundation) pour la suite des échanges alors que ladite première machine se bloque sur ledit appel dans l'attente de son retour, puis lorsque la seconde machine émet un appel RPC représentatif d'une fonction déterminée à exécuter par la io première machine) cet appel est transmis vers la machine relais qui après reconnaissance de la fonction à exécuter fe retransmet vers la première machine par retour de l'appel RPC bloqué, la première machine demandant alors les paramètres d'entrée de la fonction à exécuter présents dans la machine relais puis exécutant ladite fonction après réception desdits is paramètres d'entrée et enfin fournissant, comme paramètre de sortie, le résultat à la seconde machine via la machine relais.
Ainsi grâce au procédé de simulation selon l'invention, dans un réseau, une machine "client" peut lancer des appels de procédure RPC vers une autre Zo machine "client" utilisée comme "serveur' ("pseudo-serveur' et ceci sans modification ou recopie du code source d'une partie "serveur"; le code "client" est standard, il suffit pour cela de sélectionner un "serveur" du réseau qui servira alors de machine relais et autorisera le dialogue entre la machine "client" et fe "pseudo-serveur". En effet, ta machine "client" voit Zs alors le couple "senreur"P'pseudo-serveur" comme une machine "serveur"
homogène. Dans ces conditions tout appel RPC avec tout type de paramètre peut être exécuté. En outre, de manière générale fintertace de la procédure est décrite dans un langage de description d'intertace (IDL).
Cette interface est compilée en deux talons (appelés "stubs" par l'homme 3o du métier), un pour le cSté "client", l'autre pour le c8té "serveur" du RPC, les talons étant compilés avec les programmes "client" et "serveur"
respectivement pour donner les deux exécutables "client" et "serveur". Le talon "client" est une fonction dont l'interface respecte fintertace décrite en IDL et qui a pour but de transformer les paramètres d'appel de la ss représentation propre à la machine "client" en une représentation universelle dite représentation de réseau. Le but du talon "serveur" est de transformer les paramètres d'appel de la représentation réseau en la représentation propre à la machine senneur et d'appeler ensuite la fonction
3 effectivement demandée. Selon l'invention, le fonctionnement est automatique et conforme à la représentation réseau, toutes les conversions étant réalisées au niveau du NDR (Network Data Representation). Les talons, qui sont générés par le langage de description de l'interface, sont s donc standards. De plus) en ce qui concerne les services de sécurité, les mécanismes de protection éventuels sont également standards.
De manière remarquable, selon le présent procédé de simulation, les étapes suivantes sont chronologiquement parcourues io - la première machine émet vers une première unité d'exécution de la machine relais un appel RPC (1 ) signifiant qu'elle est préte pour l'exécution de fonctions, l'unité d'exécution de la machine relais qui gère cet appel RPC (1 ) se met alors en attente d'un signal de réveil et bloque ainsi la ~s première machine sur cet appel RPC (1)) - la machine relais informe le service de nommage que la première machine est préte à exécuter une fonction désirée, zo - la seconde machine va chercher dans un répertoire du service de nommage l'adresse de la fonction à exécuter, - la seconde machine émet alors un appel RPC (2), conforme à la représentation réseau, correspondant à la fonction à exécuter et Zs comportant les paramètres d'entrée et de sortie de ladite fonction, vers une seconde unité d'exécution de la machine relais, cette unité d'exécution se mettant en attente d'un signal de réveil et bloquant ainsi la seconde machine sur cet appel RPC(2) après avoir elle-méme émis un signal de réveil vers la première unité d'exécution en attente, - la première machine est renseignée, par retour de l'appel RPC(1 ) ainsi débloqué, sur le type de fonction à exécuter, - la première machine émet un nouvel appel RPC(3), vers la première unité
3s d'exécution de la machine relais, pour demander les paramètres d'entrée de la fonction à exécuter, cette unité d'exécution demandant lesdits paramètres à la seconde unité d'exécution de la machine relais via un mécanisme de communication interprocessus ("sockets", mémoire ~137~2U
De manière remarquable, selon le présent procédé de simulation, les étapes suivantes sont chronologiquement parcourues io - la première machine émet vers une première unité d'exécution de la machine relais un appel RPC (1 ) signifiant qu'elle est préte pour l'exécution de fonctions, l'unité d'exécution de la machine relais qui gère cet appel RPC (1 ) se met alors en attente d'un signal de réveil et bloque ainsi la ~s première machine sur cet appel RPC (1)) - la machine relais informe le service de nommage que la première machine est préte à exécuter une fonction désirée, zo - la seconde machine va chercher dans un répertoire du service de nommage l'adresse de la fonction à exécuter, - la seconde machine émet alors un appel RPC (2), conforme à la représentation réseau, correspondant à la fonction à exécuter et Zs comportant les paramètres d'entrée et de sortie de ladite fonction, vers une seconde unité d'exécution de la machine relais, cette unité d'exécution se mettant en attente d'un signal de réveil et bloquant ainsi la seconde machine sur cet appel RPC(2) après avoir elle-méme émis un signal de réveil vers la première unité d'exécution en attente, - la première machine est renseignée, par retour de l'appel RPC(1 ) ainsi débloqué, sur le type de fonction à exécuter, - la première machine émet un nouvel appel RPC(3), vers la première unité
3s d'exécution de la machine relais, pour demander les paramètres d'entrée de la fonction à exécuter, cette unité d'exécution demandant lesdits paramètres à la seconde unité d'exécution de la machine relais via un mécanisme de communication interprocessus ("sockets", mémoire ~137~2U
4 partagée avec sémaphores, files de messages, tube de communication appelé également "pipe",...) ou intraprocessus (mémoire globale protégée par des verrous par exemple).
s - après obtention des paramètres d'entrée de la fonction à exécuter, la première unité d'exécution de la machine relais transmet lesdits paramètres, par retour de l'appel RPC(3), à la première machine qui exécute la fonction, io - la première machine transmet le résultat de la fonction exécutée à la première unité d'exécution de la machine relais qui d'une part le communique à la seconde unité d'exécution via un mécanisme de communication interprocessus ("sockets", mémoire partagée avec sémaphores, files de messages, tube de communication appelé également ~s "pipe",...) ou intraprocessus (mémoire globale protégée par des verrous par exemple) et d'autre part émet un signal de réveil vers cette seconde unité
d'exécution, - la seconde unité d'exécution de la machine relais, par retour de l'appel ao RPC (2) ainsi débloqué, transmet comme paramètre de sortie ie résultat de la fonction exécutée vers la seconde machine.
De cette manière, le procédé selon l'invention peut s'appliquer à l'évidence à une pluralité de machines "client" émettant des appels RPC vers un Zs "pseudo-serveur", chaque machine "client" voyant le couple "serveur"~'pseudo-serveur" comme une machine "serveur". Le dialogue entre la machine "client" et le "pseudo-serveur" est alors autorisé par l'intermédiaire de différentes unités d'exécution de la machine relais.
3o La description suivante en regard du dessin annexé, le tout donné à titre d'exemple non limitatif, fera bien comprendre comment l'invention peut être réalisée.
La figure unique présente de manière schématique, un exemple de 3s dialogue élaboré dans un réseau autour d'appels RPC) entre une première machine "client" utilisée en "serveur" et une seconde machine "client" par l'intermédiaire d'une troisième machine "serveur" utilisée comme relais.
21a7~20 Sur la figure, une première machine PS d'architecture uniquement "client"
est désirée étre utilisée comme "serveur RPC" ("pseudo-serveur"} par une seconde machine CL d'architecture "client". Conformément à l'idée de l'invention, les différents appels RPC sont émis d'abord vers une troisième s machine RE dite machine relais, cette machine ayant une architecture "serveur".
De préférence, les machines PS, RE) CL sont des machines de type DCE
(DCE est une marque déposée par Open Software Fou~dation).
io De méme) de manière préférée mais non limitative, les appels de procédure à distance sont de type standard DCEIRPC. II est cependant rappelé qu'avantageusement tout type d'appel RPC avec tout autre type de paramètre peut étre utilisé selon le présent procédé et par exemple un is RPC selon la technologie de Sun Microsystems) un RPC NCS 1.5 ApoIlo/Hewlett.Packard (NCS : Network Computing System), un RPC selon Netwise, etc...).
Pour une meilleure appréhension du procédé selon l'invention) un exemple 2o simple est ci-après décrit. Dans cet exemple la machine CL demande à la machine PS d'exécuter une fonction d'addition en prenant comme paramètres d'entrée) les paramètres a et b à additionner et comme paramètre de sortie, le paramètre c représentant le résultat de l'addition a et b.
2s Selon le présent procédé de simulation) dans cet exemple précis) différentes étapes seront parcourues avant d'aboutir au résultat c.
Ainsi, à l'étape 1, la première machine PS émet vers une premiére unité
so d'exécution TH1 de la machine relais RE, un appel RPC 1 (représenté par une flèche en trait plein)) par exemple du type "I am ready(f nb)", signifiant qu'elle est prête pour l'exécution de fonctions (dont la fonction "add"). L'unité d'exécution TH1 de la machine RE qui reçoit et va donc gérer cet appel RPC1, se met alors en attente d'un signal de réveil qui peut 3s être une variable de condition du type (pthread_cond_wait (tond var work)), ce qui a pour effet de bloquer la première machine PS
sur l'appel RPC 1.
21~7~~0 Lors d'une seconde étape 2, la machine relais RE informe le service de nommage NS que la première machine PS est préte à exécuter la fonction désirée par la seconde machine CL, en l'occurrence ce sera la fonction d'addition "add". Sur la figure, le service de nommage NS est représenté à
s l'extérieur des machines PS, RE ou CL, cependant il peut être localisé dans l'une quelconque des machines "serveur" du réseau et donc par exemple dans RE.
La seconde machine CL) lors de l'étape 3, va chercher dans un répertoire io du service de nommage, couramment appelé CDSD ("Cell Directory Server Daemon") l'adresse (par exemple une adresse Internet) de la fonction à
exécuter, dans le cas présent la fonction "add".
Lors de l'étape 4) la seconde machine CL émet à son tour, vers une is seconde unité d'exécution TH2 de la machine RE, un appel RPC 2 (représenté par une flèche en trait plein), conforme à la représentation réseau grâce aux talons standards) cet appel correspondant à la fonction à
exécuter et comportant les paramètres d'entrée (a) b) et de sortie (c) de ladite fonction. L'appel RPC 2 peut être par exemple du type "add" (a [in], 2o b [in]) c [out])". L'unité d'exécution TH2 émet le signal de réveil attendu par la première machine PS (pthread_cond signal (tond var work)) puis se met en attente d'un signal de réveil qui peut être une variable de condition du type (pthread_cond_wait(cond var arg) ce qui a pour effet de bloquer la seconde machine CL sur l'appel RPC 2.
La premiëre machine PS est, lors de l'étape 5) renseignée sur le type de fonction à exécuter par retour de l'appel RPC 1 (représenté par une flèche en trait pointillé) ainsi débloqué) le numéro de la fonction, correspondant ici à la fonction "add", lui étant transmis. C'est donc lors de cette étape) que la 3o machine PS sait quelle fonction doit être exécutée, en l'occurrence la fonction "add" et par là même le type de paramètres à demander.
A l'étape 6, la première machine PS émet vers l'unité d'exécution TH1 de la machine RE, un nouvel appel RPC 3 (représenté par une flèche en trait 3s plein) par exemple du type "get add ([out]a,[out]b)", pour demander les paramètres d'entrée (a,b) de la fonction "add" à exécuter. L'unité
d'exécution TH1 demande alors lesdits paramètres à la seconde unité
d'exécution TH2 et les obtient via un mécanisme de communication ~1~"~~~~1 interprocessus du genre "sockets") mémoire partagée avec sémaphores, files de messages) tube de communication appelé également "pipe",... ou intraprocessus par exemple du genre mémoire globale protégée par des verrous.
s Lorsque l'unité d'exécution TH 1 de la machine RE a obtenu les paramètres d'entrée (a,b) de la fonction "add" à exécuter, elle transmet vers la première machine PS, lors de l'étape 7) lesdits paramètres (a,b) par retour de l'appel RPC 3 (représenté par une flèche en trait pointillé). La machine PS connaît à présent la fonction à exécuter "add" et les paramètres d'entrée a et b et elle exécute l'addition de a et b pour donner le résultat c=a+b.
La première machine PS transmet à l'unité d'exécution TH1 de la machine RE, lors de l'étape 8) le résultat c de la fonction ainsi exécutée) au moyen is par exemple de la fonction "set add {[in]c). L'unité d'exécution TH1 qui connaiï à présent le résultat c, le communique à l'unité d'exécution TH2 via un mécanisme de communication interprocessus ("sockets", mémoire partagée avec sémaphores) files de messages, tube de communication appelé également "pipe",...) ou intraprocessus (mémoire globale protégée ao par des verrous par exemple) puis émet vers ladite unité TH2 le signal de réveil attendu du type (pthread_cond signal(cond var arg)), ce qui aura pour effet de débloquer l'appel RPC 2.
Enfin) lors de l'étape 9) la seconde unité d'exécution TH2 de la machine Zs RE, par retour de l'appel RPC 2 (représenté par une flèche en trait pointillé) ainsi débloqué, transmet, vers la seconde machine CL) comme paramètre de sortie le résultat c=a+b de la fonction "add" exécutée.
En conclusion, comme cela vient d'étre vu) le présent procédé qui permet 3o de simuler avantageusement une architecture "serveur" à partir d'une architecture "client" peut être mis en oeuvre de manière aisée et rapide et par conséquent son application est peu onéreuse.
s - après obtention des paramètres d'entrée de la fonction à exécuter, la première unité d'exécution de la machine relais transmet lesdits paramètres, par retour de l'appel RPC(3), à la première machine qui exécute la fonction, io - la première machine transmet le résultat de la fonction exécutée à la première unité d'exécution de la machine relais qui d'une part le communique à la seconde unité d'exécution via un mécanisme de communication interprocessus ("sockets", mémoire partagée avec sémaphores, files de messages, tube de communication appelé également ~s "pipe",...) ou intraprocessus (mémoire globale protégée par des verrous par exemple) et d'autre part émet un signal de réveil vers cette seconde unité
d'exécution, - la seconde unité d'exécution de la machine relais, par retour de l'appel ao RPC (2) ainsi débloqué, transmet comme paramètre de sortie ie résultat de la fonction exécutée vers la seconde machine.
De cette manière, le procédé selon l'invention peut s'appliquer à l'évidence à une pluralité de machines "client" émettant des appels RPC vers un Zs "pseudo-serveur", chaque machine "client" voyant le couple "serveur"~'pseudo-serveur" comme une machine "serveur". Le dialogue entre la machine "client" et le "pseudo-serveur" est alors autorisé par l'intermédiaire de différentes unités d'exécution de la machine relais.
3o La description suivante en regard du dessin annexé, le tout donné à titre d'exemple non limitatif, fera bien comprendre comment l'invention peut être réalisée.
La figure unique présente de manière schématique, un exemple de 3s dialogue élaboré dans un réseau autour d'appels RPC) entre une première machine "client" utilisée en "serveur" et une seconde machine "client" par l'intermédiaire d'une troisième machine "serveur" utilisée comme relais.
21a7~20 Sur la figure, une première machine PS d'architecture uniquement "client"
est désirée étre utilisée comme "serveur RPC" ("pseudo-serveur"} par une seconde machine CL d'architecture "client". Conformément à l'idée de l'invention, les différents appels RPC sont émis d'abord vers une troisième s machine RE dite machine relais, cette machine ayant une architecture "serveur".
De préférence, les machines PS, RE) CL sont des machines de type DCE
(DCE est une marque déposée par Open Software Fou~dation).
io De méme) de manière préférée mais non limitative, les appels de procédure à distance sont de type standard DCEIRPC. II est cependant rappelé qu'avantageusement tout type d'appel RPC avec tout autre type de paramètre peut étre utilisé selon le présent procédé et par exemple un is RPC selon la technologie de Sun Microsystems) un RPC NCS 1.5 ApoIlo/Hewlett.Packard (NCS : Network Computing System), un RPC selon Netwise, etc...).
Pour une meilleure appréhension du procédé selon l'invention) un exemple 2o simple est ci-après décrit. Dans cet exemple la machine CL demande à la machine PS d'exécuter une fonction d'addition en prenant comme paramètres d'entrée) les paramètres a et b à additionner et comme paramètre de sortie, le paramètre c représentant le résultat de l'addition a et b.
2s Selon le présent procédé de simulation) dans cet exemple précis) différentes étapes seront parcourues avant d'aboutir au résultat c.
Ainsi, à l'étape 1, la première machine PS émet vers une premiére unité
so d'exécution TH1 de la machine relais RE, un appel RPC 1 (représenté par une flèche en trait plein)) par exemple du type "I am ready(f nb)", signifiant qu'elle est prête pour l'exécution de fonctions (dont la fonction "add"). L'unité d'exécution TH1 de la machine RE qui reçoit et va donc gérer cet appel RPC1, se met alors en attente d'un signal de réveil qui peut 3s être une variable de condition du type (pthread_cond_wait (tond var work)), ce qui a pour effet de bloquer la première machine PS
sur l'appel RPC 1.
21~7~~0 Lors d'une seconde étape 2, la machine relais RE informe le service de nommage NS que la première machine PS est préte à exécuter la fonction désirée par la seconde machine CL, en l'occurrence ce sera la fonction d'addition "add". Sur la figure, le service de nommage NS est représenté à
s l'extérieur des machines PS, RE ou CL, cependant il peut être localisé dans l'une quelconque des machines "serveur" du réseau et donc par exemple dans RE.
La seconde machine CL) lors de l'étape 3, va chercher dans un répertoire io du service de nommage, couramment appelé CDSD ("Cell Directory Server Daemon") l'adresse (par exemple une adresse Internet) de la fonction à
exécuter, dans le cas présent la fonction "add".
Lors de l'étape 4) la seconde machine CL émet à son tour, vers une is seconde unité d'exécution TH2 de la machine RE, un appel RPC 2 (représenté par une flèche en trait plein), conforme à la représentation réseau grâce aux talons standards) cet appel correspondant à la fonction à
exécuter et comportant les paramètres d'entrée (a) b) et de sortie (c) de ladite fonction. L'appel RPC 2 peut être par exemple du type "add" (a [in], 2o b [in]) c [out])". L'unité d'exécution TH2 émet le signal de réveil attendu par la première machine PS (pthread_cond signal (tond var work)) puis se met en attente d'un signal de réveil qui peut être une variable de condition du type (pthread_cond_wait(cond var arg) ce qui a pour effet de bloquer la seconde machine CL sur l'appel RPC 2.
La premiëre machine PS est, lors de l'étape 5) renseignée sur le type de fonction à exécuter par retour de l'appel RPC 1 (représenté par une flèche en trait pointillé) ainsi débloqué) le numéro de la fonction, correspondant ici à la fonction "add", lui étant transmis. C'est donc lors de cette étape) que la 3o machine PS sait quelle fonction doit être exécutée, en l'occurrence la fonction "add" et par là même le type de paramètres à demander.
A l'étape 6, la première machine PS émet vers l'unité d'exécution TH1 de la machine RE, un nouvel appel RPC 3 (représenté par une flèche en trait 3s plein) par exemple du type "get add ([out]a,[out]b)", pour demander les paramètres d'entrée (a,b) de la fonction "add" à exécuter. L'unité
d'exécution TH1 demande alors lesdits paramètres à la seconde unité
d'exécution TH2 et les obtient via un mécanisme de communication ~1~"~~~~1 interprocessus du genre "sockets") mémoire partagée avec sémaphores, files de messages) tube de communication appelé également "pipe",... ou intraprocessus par exemple du genre mémoire globale protégée par des verrous.
s Lorsque l'unité d'exécution TH 1 de la machine RE a obtenu les paramètres d'entrée (a,b) de la fonction "add" à exécuter, elle transmet vers la première machine PS, lors de l'étape 7) lesdits paramètres (a,b) par retour de l'appel RPC 3 (représenté par une flèche en trait pointillé). La machine PS connaît à présent la fonction à exécuter "add" et les paramètres d'entrée a et b et elle exécute l'addition de a et b pour donner le résultat c=a+b.
La première machine PS transmet à l'unité d'exécution TH1 de la machine RE, lors de l'étape 8) le résultat c de la fonction ainsi exécutée) au moyen is par exemple de la fonction "set add {[in]c). L'unité d'exécution TH1 qui connaiï à présent le résultat c, le communique à l'unité d'exécution TH2 via un mécanisme de communication interprocessus ("sockets", mémoire partagée avec sémaphores) files de messages, tube de communication appelé également "pipe",...) ou intraprocessus (mémoire globale protégée ao par des verrous par exemple) puis émet vers ladite unité TH2 le signal de réveil attendu du type (pthread_cond signal(cond var arg)), ce qui aura pour effet de débloquer l'appel RPC 2.
Enfin) lors de l'étape 9) la seconde unité d'exécution TH2 de la machine Zs RE, par retour de l'appel RPC 2 (représenté par une flèche en trait pointillé) ainsi débloqué, transmet, vers la seconde machine CL) comme paramètre de sortie le résultat c=a+b de la fonction "add" exécutée.
En conclusion, comme cela vient d'étre vu) le présent procédé qui permet 3o de simuler avantageusement une architecture "serveur" à partir d'une architecture "client" peut être mis en oeuvre de manière aisée et rapide et par conséquent son application est peu onéreuse.
Claims (11)
1. Procédé de simulation, dans un réseau, d'une architecture "serveur" à
partir d'une architecture "client" d'une première machine pour l'exécution d'appels de procédure à distance RPC émis par au moins une seconde machine d'architecture "client", caractérisé en ce que la première machine émet préalablement un appel RPC vers une troisième machine d'architecture "serveur" utilisée entre la première et la deuxième machines et pour cela appelée machine relais, cet appel RPC ouvrant un contexte de communication pour la suite des échanges alors que ladite première machine se bloque sur ledit appel dans l'attente de son retour, puis lorsque la seconde machine émet un appel RPC représentatif d'une fonction déterminée à exécuter par la première machine, cet appel est transmis vers la machine relais qui après reconnaissance de la fonction à exécuter le retransmet vers la première machine par retour de l'appel RPC bloqué, la première machine demandant alors les paramètres d'entrée de la fonction à exécuter présents dans la machine relais puis exécutant ladite fonction après réception desdits paramètres d'entrée et enfin fournissant, comme paramètre de sortie, le résultat à la seconde machine via la machine relais.
partir d'une architecture "client" d'une première machine pour l'exécution d'appels de procédure à distance RPC émis par au moins une seconde machine d'architecture "client", caractérisé en ce que la première machine émet préalablement un appel RPC vers une troisième machine d'architecture "serveur" utilisée entre la première et la deuxième machines et pour cela appelée machine relais, cet appel RPC ouvrant un contexte de communication pour la suite des échanges alors que ladite première machine se bloque sur ledit appel dans l'attente de son retour, puis lorsque la seconde machine émet un appel RPC représentatif d'une fonction déterminée à exécuter par la première machine, cet appel est transmis vers la machine relais qui après reconnaissance de la fonction à exécuter le retransmet vers la première machine par retour de l'appel RPC bloqué, la première machine demandant alors les paramètres d'entrée de la fonction à exécuter présents dans la machine relais puis exécutant ladite fonction après réception desdits paramètres d'entrée et enfin fournissant, comme paramètre de sortie, le résultat à la seconde machine via la machine relais.
2. Procédé de simulation selon la revendication 1 dans lequel les étapes suivantes sont chronologiquement parcourues:
- la première machine émet vers une première unité d'exécution de la machine relais un appel RPC (1) signifiant qu'elle est prête pour l'exécution de fonctions, l'unité d'exécution de la machine relais qui gère cet appel RPC (1) se met alors en attente d'un signal de réveil et bloque ainsi la première machine sur cet appel RPC (1), - la machine relais informe le service de nommage que la première machine est prête à exécuter une fonction désirée, - la seconde machine va chercher dans un répertoire du service de nommage l'adresse de la fonction à exécuter, - la seconde machine émet alors un appel RPC (2), conforme à la représentation réseau, correspondant à la fonction à exécuter et comportant les paramètres d'entrée et de sortie de ladite fonction, vers une seconde unité d'exécution de la machine relais, cette unité d'exécution se mettant en attente d'un signal de réveil et bloquant ainsi la seconde machine sur cet appel RPC(2) après avoir elle-même émis un signal de réveil vers la première unité d'exécution en attente, - la première machine est renseignée, par retour de l'appel RPC(1) ainsi débloqué, sur le type de fonction à exécuter, - la première machine émet un nouvel appel RPC(3), vers la première unité
d'exécution de la machine relais pour demander les paramètres d'entrée de la fonction à exécuter, cette unité d'exécution demandant lesdits paramètres à la seconde unité d'exécution de la machine relais via un mécanisme de communication interprocessus ("sockets", mémoire partagée avec sémaphores, files de messages, tube de communication appelé également "pipe",...) ou intraprocessus (mémoire globale protégée par des verrous,...).
- après obtention des paramètres d'entrée de la fonction à exécuter, la première unité d'exécution de la machine relais transmet lesdits paramètres, par retour de l'appel RPC(3), à la première machine qui exécute la fonction, - la première machine transmet le résultat de la fonction exécutée à la première unité d'exécution de la machine relais qui d'une part le communique à la seconde unité d'exécution via un mécanisme de communication interprocessus ("sockets", mémoire partagée avec sémaphores, files de messages, tube de communication appelé également "pipe",...) ou intraprocessus (mémoire globale protégée par des verrous,...) et d'autre part émet un signal de réveil vers cette seconde unité
d'exécution, - la seconde unité d'exécution de la machine relais, par retour de l'appel RPC (2) ainsi débloqué, transmet comme paramètre de sortie le résultat de la fonction exécutée vers la seconde machine.
- la première machine émet vers une première unité d'exécution de la machine relais un appel RPC (1) signifiant qu'elle est prête pour l'exécution de fonctions, l'unité d'exécution de la machine relais qui gère cet appel RPC (1) se met alors en attente d'un signal de réveil et bloque ainsi la première machine sur cet appel RPC (1), - la machine relais informe le service de nommage que la première machine est prête à exécuter une fonction désirée, - la seconde machine va chercher dans un répertoire du service de nommage l'adresse de la fonction à exécuter, - la seconde machine émet alors un appel RPC (2), conforme à la représentation réseau, correspondant à la fonction à exécuter et comportant les paramètres d'entrée et de sortie de ladite fonction, vers une seconde unité d'exécution de la machine relais, cette unité d'exécution se mettant en attente d'un signal de réveil et bloquant ainsi la seconde machine sur cet appel RPC(2) après avoir elle-même émis un signal de réveil vers la première unité d'exécution en attente, - la première machine est renseignée, par retour de l'appel RPC(1) ainsi débloqué, sur le type de fonction à exécuter, - la première machine émet un nouvel appel RPC(3), vers la première unité
d'exécution de la machine relais pour demander les paramètres d'entrée de la fonction à exécuter, cette unité d'exécution demandant lesdits paramètres à la seconde unité d'exécution de la machine relais via un mécanisme de communication interprocessus ("sockets", mémoire partagée avec sémaphores, files de messages, tube de communication appelé également "pipe",...) ou intraprocessus (mémoire globale protégée par des verrous,...).
- après obtention des paramètres d'entrée de la fonction à exécuter, la première unité d'exécution de la machine relais transmet lesdits paramètres, par retour de l'appel RPC(3), à la première machine qui exécute la fonction, - la première machine transmet le résultat de la fonction exécutée à la première unité d'exécution de la machine relais qui d'une part le communique à la seconde unité d'exécution via un mécanisme de communication interprocessus ("sockets", mémoire partagée avec sémaphores, files de messages, tube de communication appelé également "pipe",...) ou intraprocessus (mémoire globale protégée par des verrous,...) et d'autre part émet un signal de réveil vers cette seconde unité
d'exécution, - la seconde unité d'exécution de la machine relais, par retour de l'appel RPC (2) ainsi débloqué, transmet comme paramètre de sortie le résultat de la fonction exécutée vers la seconde machine.
3. Procédé de simulation selon la revendication 2 pour lequel les machines sont des machines de type DCE.
4. Procédé de simulation selon la revendication 2 ou 3 dans lequel les appels de procédure à distance sont de type standard DCE/RPC.
5. Procédé de simulation selon la revendication 2 ou 3 dans lequel tout type d'appel de procédure à distance RPC est utilisé pour les communications entre machines.
6. Procédé de simulation, dans un réseau, d'une architecture "serveur" dans une première machine pour l'exécution d'appels de procédures à distance RPC émis par au moins une seconde machine d'architecture "client", comprenant les étapes suivantes:
émettre un appel RPC de la première machine vers une première unité d'exécution d'une troisième machine, appelée machine relais ayant une architecture "serveur" et qui est utilisé entre les première et seconde machines, ledit appel RPC mettant en marche un contexte de communication pour une suite d'échanges alors que ladite première machine se bloque sur ledit appel dans l'attente de son retour;
chercher à l'aide de la seconde machine dans un répertoire d'un service de nommage l'adresse d'une fonction à exécuter, alors que lorsque la seconde machine émet un appel RPC qui représente une fonction prédéterminée à exécuter par la première machine vers une seconde unité
d'exécution de la machine relais, ladite seconde unité d'exécution se mettant en attente d'un signal de réveil et bloquant la seconde machine sur cet appel RPC après avoir elle-même émis un signal de réveil vers la première unité
d'exécution en attente;
transmettre ledit appel à la machine relais qui, après avoir reconnu la fonction à exécuter, retransmet ledit appel à la première machine par retour de l'appel RPC bloqué;
émettre alors un appel RPC de la première machine vers la première unité d'exécution de la machine relais via un mécanisme de communication interprocessus pour demander des paramètres d'entrée de la fonction à exécuter qui sont présents dans la seconde unité d'exécution de la machine relais;
exécuter alors ladite fonction à exécuter après avoir reçu lesdits paramètres d'entrée; et finalement, fournir le résultat sous la forme d'un paramètre de sortie à la seconde machine via l'unité d'exécution de la machine relais.
émettre un appel RPC de la première machine vers une première unité d'exécution d'une troisième machine, appelée machine relais ayant une architecture "serveur" et qui est utilisé entre les première et seconde machines, ledit appel RPC mettant en marche un contexte de communication pour une suite d'échanges alors que ladite première machine se bloque sur ledit appel dans l'attente de son retour;
chercher à l'aide de la seconde machine dans un répertoire d'un service de nommage l'adresse d'une fonction à exécuter, alors que lorsque la seconde machine émet un appel RPC qui représente une fonction prédéterminée à exécuter par la première machine vers une seconde unité
d'exécution de la machine relais, ladite seconde unité d'exécution se mettant en attente d'un signal de réveil et bloquant la seconde machine sur cet appel RPC après avoir elle-même émis un signal de réveil vers la première unité
d'exécution en attente;
transmettre ledit appel à la machine relais qui, après avoir reconnu la fonction à exécuter, retransmet ledit appel à la première machine par retour de l'appel RPC bloqué;
émettre alors un appel RPC de la première machine vers la première unité d'exécution de la machine relais via un mécanisme de communication interprocessus pour demander des paramètres d'entrée de la fonction à exécuter qui sont présents dans la seconde unité d'exécution de la machine relais;
exécuter alors ladite fonction à exécuter après avoir reçu lesdits paramètres d'entrée; et finalement, fournir le résultat sous la forme d'un paramètre de sortie à la seconde machine via l'unité d'exécution de la machine relais.
7. Procédé de simulation selon la revendication 6, pour lequel les machines sont des machines du type DCE.
8. Procédé de simulation selon la revendication 7, dans lequel les appels de procédure à distance sont de type standard DCE/RPC.
9. Procédé de simulation selon la revendication 7, dans lequel tout type d'appel de procédure à distance RPC est utilisé pour les communications entre machines.
10. Procédé de simulation selon la revendication 6, dans lequel les appels de procédure à distance sont de type standard DCE/RPC.
11. Procédé de simulation selon la revendication 10, dans lequel tout type d'appel de procédure à distance RPC est utilisé pour les communications entre machines.
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR9315947A FR2714300B1 (fr) | 1993-12-24 | 1993-12-24 | Appareil de filtration du type cylindre rotatif à dépression intérieure. |
| FR9315947 | 1993-12-31 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CA2137620A1 CA2137620A1 (fr) | 1995-07-01 |
| CA2137620C true CA2137620C (fr) | 1999-10-05 |
Family
ID=9454633
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CA002137620A Expired - Fee Related CA2137620C (fr) | 1993-12-24 | 1994-12-08 | Procede de simulation d'une architecture "serveur" a partir d'une architecture "client" |
Country Status (2)
| Country | Link |
|---|---|
| CA (1) | CA2137620C (fr) |
| FR (1) | FR2714300B1 (fr) |
Families Citing this family (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| GB9906470D0 (en) * | 1999-03-19 | 1999-05-12 | Jones & Attwood Ltd | Sewage screening apparatus |
| US6267889B1 (en) | 2000-01-26 | 2001-07-31 | Mdf, Llc | Rotary drum filter |
| KR100826535B1 (ko) * | 2007-02-20 | 2008-05-02 | 엘지전자 주식회사 | 필터 청소장치 및 이를 구비한 덕트리스 건조기 |
Family Cites Families (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| DE420563C (de) * | 1924-03-21 | 1925-10-27 | Paul Pape | Drehbare Filtersaugtrommel mit ueber die Trogwaende hinaus verlaengerten Lagerhaelsen |
| US2583698A (en) * | 1949-04-30 | 1952-01-29 | Komline Sanderson Eng Corp | Rotary drum vacuum filter |
| FR2029525A1 (fr) * | 1969-01-28 | 1970-10-23 | Fmc Corp | |
| CH613629A5 (en) * | 1977-02-23 | 1979-10-15 | Technical Fabricators | Rotary filter |
| DE4019500A1 (de) * | 1990-06-19 | 1992-01-09 | Hydac Technology Gmbh | Filtermittel sowie verfahren zu seiner herstellung und seine verwendung |
-
1993
- 1993-12-24 FR FR9315947A patent/FR2714300B1/fr not_active Expired - Fee Related
-
1994
- 1994-12-08 CA CA002137620A patent/CA2137620C/fr not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| FR2714300A1 (fr) | 1995-06-30 |
| FR2714300B1 (fr) | 1997-04-25 |
| CA2137620A1 (fr) | 1995-07-01 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| EP0665494A1 (fr) | Circuit décodeur insensible à la fluctuation de tension d'alimentation | |
| Tanenbaum et al. | The Amoeba distributed operating system—a status report | |
| EP0572307B1 (fr) | Système logiciel à objets répliqués exploitant une messagerie dynamique, notamment pour installation de contrÔle/commande à architecture redondante | |
| EP0843259A1 (fr) | Système de gestion et de traitement de transactions distribuées d'objets et procédé d'objets et procédé mis en oeuvre par ledit système | |
| US7080120B2 (en) | System and method for collaborative processing of distributed applications | |
| US6470342B1 (en) | Process of maintaining a distributed map of transaction identifiers and using hashing to access these maps | |
| FR2722591A1 (fr) | Systeme informatique ouvert a serveurs multiples | |
| US20030135587A1 (en) | Method and system of state management for data communications | |
| EP0611210B1 (fr) | Procédé d'administration d'applications avec des protocoles standards | |
| CA2137620C (fr) | Procede de simulation d'une architecture "serveur" a partir d'une architecture "client" | |
| FR2737028A1 (fr) | Architecture d'habillage d'applications pour une plate-forme informatique | |
| EP0178235B1 (fr) | Procédé et dispositif électronique pour l'exécution répartie d'une activité entre plusieurs sites différents | |
| FR3031822A1 (fr) | Telechargement de donnees sur un equipement distant | |
| EP1907931A1 (fr) | Architecture a composants logiciels pour les applications a plate-forme d'execution donnant acces au niveau metaprogramme | |
| FR2643167A1 (fr) | Machine a protocole | |
| EP2223215B1 (fr) | Procédé de contrôle d'au moins un processus applicatif et produit programme d'ordinateur correspondant | |
| FR2696256A1 (fr) | Utilisation de "tubes" pour le transfert d'états entre différents systèmes distants. | |
| WO2019129957A1 (fr) | Procede de controle de la gestion des traces d'evenements dans l'execution d'une application informatique sur une machine informatique | |
| FR2862830A1 (fr) | Dispositif et procede asynchrones et automatiques de transmission de resultats entre objets communicants. | |
| EP1045306B1 (fr) | Procédé de modification d'un protocole entre objets distribués | |
| KR970078205A (ko) | 클라이언트-서버 분산 트랜잭션 통신 제어방식 | |
| FR2688608A1 (fr) | Utilisation d'un langage ayant une representation similaire pour les programmes et les donnees en informatique distribuee. | |
| EP1056000A1 (fr) | Procédé de commande, à partir d'un tableau de bord d'une station cliente, d'un processus s'exécutant sur un serveur | |
| FR2932343A1 (fr) | Procede de communication sur un reseau au moyen d'un lien | |
| FR2935505A1 (fr) | Systeme informatique a serveur d'acces simplifie, et procede correspondant |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| EEER | Examination request | ||
| MKLA | Lapsed |