Premier exemple: interprétation de commandes sur un ordinateur distant

Transcription

1 Premier exemple: interprétation de commandes sur un ordinateur distant L'utilisateur tape, sur la console T de la machine M1, des commandes destinées à la machine M2. En régime, on souhaite que le processus "shell" : ait été démarré au préalable et s'exécute sur M2, lise et interprète les commandes provenant de la console T. Description du matériel Un réseau interconnecte M1, M2 et d'autres systèmes Contrainte : on veut un shell standard (pas question de le modifier!) 1 sur 25 01/06/ :27

2 Architecture de l'application Les processus telnet et telnetd gèrent la communication: telnet re çoit les caractères provenant de la console Un circuit virtuel est établi à travers le réseau entre telnet et telnetd. Pseudo interface série pour la communication entre telnetd et le shell: cette interface virtuelle donne au shell l'illusion d'être directement connecté à une console Remarque : communication entre telnetd (fils) et le shell Contrainte : on ne peut pas modifier le shell pour l'adapter à l'environnement réseau parce qu'il peut lancer d'autres programmes et qu'il faudrait les adapter tous! Rappel : le shell est conçu pour lire/écrire sur des fichiers spéciaux associés à des terminaux, pas sur des sockets! Solution : les pseudo-terminaux (pty) (la console d'un système UNIX ou une fenêtre "terminal" telle que xterm ou gnome terminal se présentent aussi au shell et aux programmes qu'il lance à travers un pseudo-terminal: c'est 2 sur 25 01/06/ :27

3 vers lui que sont dirigés par défaut stdin, stdout et stderr) une paire d'interfaces virtuelles : un maître et un esclave (virtuelles car ces fichiers spéciaux ne correspondent pas à de vrais périphériques physiques) permet à telnetd (le fils) de communiquer avec le shell apparaît comme un vrai terminal pour le shell telnetd (le fils) sait, lui, qu'il simule un terminal pour le shell telnetd (le fils) accède à l'interface maître fichier spécial /dev/ptypn file descriptor fd1 le shell accède à l'interface esclave fichier spécial /dev/ttypn file descriptors stdin, stdout, stderr Remarque : communication entre telnetd (fils) et le shell Contrainte : on ne peut pas modifier le shell pour l'adapter à l'environnement réseau parce qu'il peut lancer d'autres programmes et qu'il faudrait les adapter tous! Rappel : le shell est conçu pour lire/écrire sur des fichiers spéciaux associés à des terminaux, pas sur des sockets! Solution : les pseudo-terminaux (pty) (la console d'un système UNIX ou une fenêtre "terminal" telle que xterm ou gnome terminal se présentent aussi au shell et aux programmes qu'il lance à travers un pseudo-terminal: c'est vers lui que sont dirigés par défaut stdin, stdout et stderr) une paire d'interfaces virtuelles : un maître et un esclave (virtuelles car ces fichiers spéciaux ne correspondent pas à de vrais périphériques physiques) permet à telnetd (le fils) de communiquer avec le shell apparaît comme un vrai terminal pour le shell telnetd (le fils) sait, lui, qu'il simule un terminal pour le shell 3 sur 25 01/06/ :27

4 telnetd (le fils) accède à l'interface maître fichier spécial /dev/ptypn file descriptor fd1 le shell accède à l'interface esclave fichier spécial /dev/ttypn file descriptors stdin, stdout, stderr Clavier -> telnet -> telnetd -> shell Ecran <- telnet <- telnetd <- shell Le processus "telnet" re çoit des caractères de T et les envoie à M2 re çoit des caractères de M2 et les envoie à T Le processus "telnetd" re çoit des caractères de M1 et les envoie au "shell" via une pseudo interface série (voir section 3.3: pty: c'est une fonction du noyau qui permet à un processus de se faire passer pour un terminal aux yeux d'un autre procesus) re çoit des caractères du "shell" via cette pseudo interface série et les envoie à M1 Le processus shell re çoit et interprète les caractères en provenance de M1 via telnetd et la pseudo interface série génère des caractères et les envoie à M1 via la pseudo interface série et telnetd. Le processus "telnet" re çoit des caractères de T et les envoie à M2 re çoit des caractères de M2 et les envoie à T Le processus "telnetd" re çoit des caractères de M1 et les envoie au "shell" via une pseudo interface série (voir section 3.3: pty: c'est une fonction du noyau qui permet à un processus de se faire passer pour un terminal aux yeux d'un autre procesus) re çoit des caractères du "shell" via cette pseudo interface série et les envoie à M1 Le processus shell 4 sur 25 01/06/ :27

5 re çoit et interprète les caractères en provenance de M1 via telnetd et la pseudo interface série génère des caractères et les envoie à M1 via la pseudo interface série et telnetd. Remarque : le concept de port Un port est une manière d'identifier différentes communications qui passent par une même interface réseau Le nombre de communications associées avec un port dépend de la nature du port (on y reviendra en d&eacure;tails) : si le port est "épheacute;mère" et alloué dynamiquement par le système, ce nombre est 0 ou 1 sinon, le port est "r&eacure;serv " et "bien connu" et ce nombre est >= 0 Une communication est identifiée par un quadruplet (on y reviendra) Le nombre de communications associées avec un port dépend de la nature du port (on y reviendra en d&eacure;tails) : si le port est "épheacute;mère" et alloué dynamiquement par le système, ce nombre est 0 ou 1 sinon, le port est "r&eacure;serv " et "bien connu" et ce nombre est >= 0 Une communication est identifiée par un quadruplet (on y reviendra) référencé par les processus pour établir des communications entre processus identifié par un numéro de port (p.n.) Les port "numbers" sont locaux aux machines : un m ême p.n. existe sur différentes machines. Les port "numbers" sont locaux aux machines : un m ême p.n. existe sur différentes machines. Il y a de nombreux ports dans le noyau 5 sur 25 01/06/ :27

6 Remarque : communication entre telnet et telnetd Répartition des rôles Rôle de client : prendre l'initiative de la communication avec l'interlocuteur (telnet joue ce rôle ) Rôle de serveur : attendre d'être contacté par le client (telnetd joue ce rôle) Le scénario Premier acte : Le processus serveur attend une demande de communication Deuxième acte : un processus client appelle le processus serveur Troisième acte: les noyaux de M1 et M2 établissent un circuit virtuel Quatrième acte : le client et le serveur communiquent Acte final : le client ou le serveur coupe la communication Remarque : Comment accéder à telnetd sur M2 Question : comment peut-on appeler (désigner) telnetd de l'extérieur de M2? M2 est identifiée par son "adresse" sur le réseau telnetd est identifié par le numéro de port 23, réservé et bien connu de 6 sur 25 01/06/ :27

7 tous sur M2 réservé : non partageable entre des serveurs différents. mais partageable entre plusieurs instances d'un m ême serveur bien connu de tous : convention pour tous les systèmes. ce numéro de port désigne le serveur "telnetd" sur tous les systèmes réservé : non partageable entre des serveurs différents. mais partageable entre plusieurs instances d'un m ême serveur bien connu de tous : convention pour tous les systèmes. ce numéro de port désigne le serveur "telnetd" sur tous les systèmes telnet désigne telnetd par: < adresse de M2, numéro de port telnetd > Remarque: comment désigner telnet sur M1 Question : comment peut-on appeler (désigner) telnet de l'extérieur de M1? M1 est identifiée par son "adresse" sur le réseau 7 sur 25 01/06/ :27

8 telnet est identifié par un numéro de port éphémère et alloué dynamiquement sur M1 un numéro de port inutilisé est alloué automatiquement sur M1 au troisième acte => le numéro de port éphémère et alloué dynamiquement n'est utilisé que pour un seul circuit virtuel (dans ce cas) éphémère : durée de vie restreinte à cette communication interprocessus => désalloué lorsque le circuit virtuel est fermé un numéro de port inutilisé est alloué automatiquement sur M1 au troisième acte => le numéro de port éphémère et alloué dynamiquement n'est utilisé que pour un seul circuit virtuel (dans ce cas) éphémère : durée de vie restreinte à cette communication interprocessus => désalloué lorsque le circuit virtuel est fermé Dans notre application, le numéro de port du client pourrait, par exemple, être Par convention, les ports éphémères re çoivent des p.n. inutilis és à partir de 1024 Par convention, les ports éphémères re çoivent des p.n. inutilis és à partir de 1024 Note : Pour les protocoles utilisés par telnet (TCP/IP), identifier un circuit virtuel se fait en identifiant les deux extrémités L'identification d'un seul c ôté n'est pas toujours suffisante pour identifier un circuit virtuel : du c ôté du serveur, plusieurs circuits virtuels peuvent correspondre au m ême p.n. L'identification d'un seul c ôté n'est pas toujours suffisante pour identifier un circuit virtuel : du c ôté du serveur, plusieurs circuits virtuels peuvent correspondre au m ême p.n. Dans notre application, les extr émit és sont identifi ées par: Côté client : < adresse de M1, p.n > Côté serveur : < adresse de M2, p.n. 23 > => Un circuit virtuel TCP est identifié par un quadruplet. Plus précisément, il s'agit d'un quintuplet : 8 sur 25 01/06/ :27

9 protocole de transport (p.ex. TCP), adresse de l'interface réseau de la machine cliente, numéro de port du client, adresse de l'interface réseau de la machine serveur, numéro de port du serveur Mais, pour simplifier l'exemple, nous ne distiguons pas adresse de machine et adresse d'interface réseau, car la plupart des machines n'ont qu'une seule interface réseau. Par ailleurs, l'autre protocole de transport de l'internet (UDP) est un protocole à datagrammes et non à circuits virtuels. => Un circuit virtuel TCP est identifié par un quadruplet. Plus précisément, il s'agit d'un quintuplet : protocole de transport (p.ex. TCP), adresse de l'interface réseau de la machine cliente, numéro de port du client, adresse de l'interface réseau de la machine serveur, numéro de port du serveur Mais, pour simplifier l'exemple, nous ne distiguons pas adresse de machine et adresse d'interface réseau, car la plupart des machines n'ont qu'une seule interface réseau. Par ailleurs, l'autre protocole de transport de l'internet (UDP) est un protocole à datagrammes et non à circuits virtuels. Dans notre application le circuit virtuel est identifi é par:: < adresse de M1, p.n. 1030, adresse de M2, p.n. 23 > Remarque : Accès à un circuit virtuel dans un processus UNIX On accède à un circuit virtuel à travers un socket descriptor, local au processus. Ces sockets sont appelés "sockets de Berkeley". C'est une interface programmatique de réseau parmi d'autres telles que TLI. Cependant, les sockets est la plus couramment utilisée. Ces sockets sont appelés "sockets de Berkeley". C'est une interface programmatique de réseau parmi d'autres telles que TLI. Cependant, les sockets est la plus couramment utilisée. 9 sur 25 01/06/ :27

10 écrire un message sur un socket descriptor=envoyer le message lire un message sur un socket descriptor=recevoir le message Le socket descriptor doit être explicitement créé associé à l'extrémité locale du circuit virtuel Dans notre application : "sd1" and "sd"» sont les deux extrémités du circuit virtuel «sdw» n'est pas associé à un circuit virtuel mais on peut cependant dire qu'il est associé au p.n. 23 (on y reviendra). "sd1" and "sd"» sont les deux extrémités du circuit virtuel «sdw» n'est pas associé à un circuit virtuel mais on peut cependant dire qu'il est associé au p.n. 23 (on y reviendra). Création et initialisation des socket descriptors: côté telnet (client) 10 sur 25 01/06/ :27

11 socket(): appel système qui crée sd1 connect(): appel système qui établit le circuit virtuel associe sd1 à son extrémité locale côté telnetd (server) Deux socket descriptors sdw pour attendre une requête du client sd2 attaché à l'extrémité locale du circuit virtuel Quatre étapes Première étape : création et initialisation de sdw sdw créé par l'appel système socket() sdw associé au p. n. 23 (par l'appel système bind()) 11 sur 25 01/06/ :27

12 Deuxième étape : le processus telnetd attend un appel (de telnet) sur sdw appel système accept() Troisième étape : lorsque telnetd est appelé par telnet le circuit virtuel est établi sd2 est créé et associé à l'extrémité locale du circuit virtuel Quatrième étape : le processus telnetd crée un fils (appel système fork) et ensuite : le processus père ferme sd2 et attend d'autres appels sur sdw (deuxième étape) le processus fils ferme sdw et commence à transmettre au shell les caractères reçus de telnet et vice-versa 12 sur 25 01/06/ :27

13 Si un autre client telnet appelle telnetd-père (c'est lui qui attend les demandes de connexion), un autre circuit virtuel est établi et un nouveau socket est créé; il est associé à nouveau au sd2 de telnetd-père, puisque celui-ci a été libéré. telnetd-père crée un autre fils Note : quoique les deux circuits virtuels correspondent au même numéro de port sur M2, ils y sont distingués par l'adresse réseau et le numéro de port du client. Pour couper la communication : il suffit qu'un des deux processus ferme son socket descriptor 13 sur 25 01/06/ :27

14 Pour couper la communication : il suffit qu'un des deux processus ferme son socket descriptor Second exemple : obtention d'information sur la charge d'une machine distante La commande rup Motivation Un utilisateur, travaillant sur la machine A voudrait savoir si la machine B est moins chargée que A Si c'était le cas, il pourrait travailler à distance sur B grâce à telnet/telnetd. Le problème Comment déterminer la charge de B avec une commande lancée sur A? Première solution Supposons que la commande w -s calcule et affiche la charge de la 14 sur 25 01/06/ :27

15 machine sur laquelle on l'exécute. La première solution consiste simplement à se loguer sur la machine B et à y exécuter w-s. Cette solution simpliste est présentée ici afin de mettre en évidence les aspects de la commande rup qui sont indépendants des aspects réseau et communication. La mesure de la charge utilisée par w et rup est le nombre moyen de processus en attente d'exécution dans la file d'attente de l'ordonnanceur au cours de la derni ère, des 5 et 15 derni ères minutes. sont affichées. La première solution consiste simplement à se loguer sur la machine B et à y exécuter w-s. Cette solution simpliste est présentée ici afin de mettre en évidence les aspects de la commande rup qui sont indépendants des aspects réseau et communication. La mesure de la charge utilisée par w et rup est le nombre moyen de processus en attente d'exécution dans la file d'attente de l'ordonnanceur au cours de la derni ère, des 5 et 15 derni ères minutes. sont affichées. A% telnet B... B% w -s 9:34am up 3 days, 22:28, 4 users, load average: 0.29, 0.18, 0.01 User tty idle what mfd p0 vi hb p1 50 csh fg p2 15:52 csh em p3 40 csh B% Avantage: pas besoin de nouveau programme Inconvénients pas vraiment ce qu'on demandait puisqu'on voulait une commande à exécuter sur la machine A...; ici, on se logge sur B et on y ex écute la commande puisqu'on voulait une commande à exécuter sur la machine A...; ici, on se logge sur B et on y ex écute la commande 15 sur 25 01/06/ :27

16 pas très efficace puisqu'on doit d'abord se loguer explicitement sur B, ce qui prend du temps (login, mot de passe). Deuxième solution Soit Q(hostname) {request_load_of_hostname; wait_for_a_reply; receive_reply_from_hostname_and_display_it; } et R do {wait_for_a_load_request; compute_load_of_the_host; send_load_to_requester; } until (finished) Pour résoudre le problème: exécuter R sur la machine B exécuter Q(B) sur la machine A Question: Est-ce que Q et R peuvent utiliser les mêmes mécanismes de communication que telnet? Oui, mais ce serait trop cher... Etablir et fermer la connexion de Q agrave; R co ûte plus cher que l'échange d'informations proprement dit. < /P> Etablir et fermer la connexion de Q agrave; R co ûte plus cher que l'échange d'informations proprement dit. < /P> On préférera une communication sans connexion dans le cas présent: les processus échangeront des MESSAGES, appelés DATAGRAMMES sans établir ni libérer de circuit virtuel Datagrammes ou Circuits Virtuels (communication sans connexion ou orientée-connexion) 16 sur 25 01/06/ :27

17 On ne garantit ni que les datagrammes arrivent à destination ni qu'ils soient reçus dans l'ordre où on les a envoyés Communication par datagrammes Supposons que le processus P1 sur A veuille envoyer un message au processus P2 sur B. P1 (émetteur) sd1=socket(datagram) bind(sd1, PORT1) 1re étape: chaque processus crée un socket P2 (récepteur) sd2=socket(datagram) 2me étape: chaque processus attache son socket à un port bind(sd2, PORT2) 3me étape: les deux processus sont prêts à communiquer: l'un émet et l'autre reçoit sendto(sd1,"hello",port2,adresse(b)) Notez l'asymétrie entre émetteur et récepteur: recvfrom(sd2, msg, from) l'émetteur doit désigner le récepteur (adresse réseau, p.n.) le récepteur reçoit de n'importe quel émetteur Commentaires: Première étape: Le concept de socket a été introduit dans l'exemple telnet. Nous utilisons ici une autre sorte de socket (famille de sockets). Deuxième étape: Ce n'est pas tout à fait vrai: seul le processus qui veut recevoir doit donner un numéro de port à son socket pour que l'émetteur puisse le désigner sans ambigu ïté. L'émetteur n'est pas obligé de donner un numéro de port à son socket. S'il ne le fait pas, le sytème donnera automatiquement un numéro de port au socket afin d'obtenir le quintuplet qui identifiera la communication. Troisième étape: Si chaque processus a donné un numéro de port à son socket, ils sont "équivalents", c-à-d, tous deux peuvent émettre et recevoir des données Commentaires: Première étape: Le concept de socket a été introduit dans 17 sur 25 01/06/ :27

18 l'exemple telnet. Nous utilisons ici une autre sorte de socket (famille de sockets). Deuxième étape: Ce n'est pas tout à fait vrai: seul le processus qui veut recevoir doit donner un numéro de port à son socket pour que l'émetteur puisse le désigner sans ambigu ïté. L'émetteur n'est pas obligé de donner un numéro de port à son socket. S'il ne le fait pas, le sytème donnera automatiquement un numéro de port au socket afin d'obtenir le quintuplet qui identifiera la communication. Troisième étape: Si chaque processus a donné un numéro de port à son socket, ils sont "équivalents", c-à-d, tous deux peuvent émettre et recevoir des données Note: P1 et P2 peuvent aussi utiliser ces sockets pour communiquer avec n'importe quel processus de n'importe quelle machine. C'est une autre différence entre datagrammes et circuits virtuels. Un circuit virtuel est établi entre deux processus. Dans une communication basée sur des datagrammes, on n'est pas obligé de se limiter à un seul interlocuteur par socket. C'est une autre différence entre datagrammes et circuits virtuels. Un circuit virtuel est établi entre deux processus. Dans une communication basée sur des datagrammes, on n'est pas obligé de se limiter à un seul interlocuteur par socket. Impact sur Q(hostname) et R Processus Q(hostname) { /* Create a socket */ sdc = socket(datagram); /* Give a name to this socket */ bind(sdc, PORT1); /* Send load request and receive reply*/ sendto(sdc, load_request_msg,port2, address(hostname)); recvfrom(sdc, load, from); /* Display result */ display(load); } On suppose ici que Q (hostname) conna ît PORT2. Dans notre cas, PORT2 est le numéro de port bien connu associé au service "who" (c-à-d 513) On suppose ici que Q (hostname) conna ît PORT2. Dans notre cas, 18 sur 25 01/06/ :27

19 PORT2 est le numéro de port bien connu associé au service "who" (c-à-d 513) Processus R { /* Create a socket */ sds = socket(datagram); /* Give a name to this socket */ bind(sds, PORT2); /* Main Loop */ while(not_finished) {recvfrom(sds, query, from); compute_load_of_the_host; sendto(sds, load, from.port, from.address); } } Un nouveau problème On ne se limite plus à une paire de machines. On considère le cas plus général d'un ensemble de machines. On ne se limite plus à une paire de machines. On considère le cas plus général d'un ensemble de machines. Au moyen d'une commande sur A, déterminer la charge de toutes les machines qui sont sur le même réseau que A. Motivation Un utilisateur sur A, voudrait connaître la meilleure machine (c-à-d la moins chargée) pour y travailler via telnet. L'administrateur système voudrait se faire une idée de la charge de son parc de machines. Première solution Utiliser Q(hostname) sur A, pour chaque hostname du réseau. Problèmes: disponibilité de la liste des hostnames des machines du réseau? s'il y a beaucoup de machines, il faudra lancer Q(...) de nombreuses fois, et créer de nombreux processus consomme plus de ressources qu'en créer un seul qui fait tout le travail. 19 sur 25 01/06/ :27

20 Deuxième solution Transformer Q(hostname) pour qu'il utilise la diffusion ( BROADCAST) Un BROADCAST == UN message envoyé à TOUTES les machines du réseau en UNE SEULE opération. Ce résultat est obtenu grâce à une adresse de machine spéciale reservée pour les diffusions. Un message envoyé à cette adresse sera reçu par chaque machine connectée au même réseau. Sur chaque machine, on vérifie s'il existe un processus destination possible comme on l'aurait fait pour un message "normal", c-à-d en cherchant un processus en attente sur le numéro de port spécifié dans le message. Sur chaque machine, on vérifie s'il existe un processus destination possible comme on l'aurait fait pour un message "normal", c-à-d en cherchant un processus en attente sur le numéro de port spécifié dans le message. Impact sur Q(hostname) et R R reste tel quel. Q(hostname) doit être adapté: pour diffuser sa requète pour recevoir plusieurs réponses => Q(hostname) { /* Create a socket, name it * and send load request */ sdc = socket(datagram); bind(sdc, PORT1); sendto(sdc, load_request_msg, PORT2, address(hostname)); if(hostname!= BROADCAST) then {/* Single reply expected */ recvfrom(s, load, from); display(load); } 20 sur 25 01/06/ :27

21 else /* Several replies expected */ while (not_finished) do {recvfrom(s, load, from); display(from: load); } } Problème: comment Q(BROADCAST) sait-il qu'il a fini? 3 possibilités: on l'arrête manuellement après un délai prédéfini après avoir reçu un nombre donné de réponses. Note: l'architecture présentée pour Q(hostname) et pour R est la base de l'implémentation de deux programmes UNIX : rup et rstatd Architecture de rup et rstatd Structurée selon le modèle client/server. Dans ce modèle, le serveur: est un processus qui attend d'être contacté par un processus client travaille pour le client. Dans notre example: rstatd attend d'être contacté par rup Lorsqu'il reçoit la demande de rup, rstatd calcule sa charge et lui renvoie le résultat rup est donc un client du serveur rstatd. rstatd peut avoir d'autres clients que rup! En fait, perfmeter, lb, istat, etc. envoient aussi des requêtes à rstatd rstatd peut avoir d'autres clients que rup! En fait, perfmeter, lb, istat, etc. envoient aussi des requêtes à rstatd 21 sur 25 01/06/ :27

22 Une autre architecture: modèle diffusion/collection de ruptime et rwhod ruptime et rwhod sont deux programmes UNIX qui rendent le même service que rup/rstad. Leur architecture est entièrement différente. Architecture de ruptime et rwhod rwhod est un programme qui s'exécute sur chaque machine. rwhod se compose de deux parties: rwhod_send et rwhod_receive. 22 sur 25 01/06/ :27

23 Toutes les k secondes, rwhod_send: calcule la charge de la machine où il s'exécute et la diffuse sur le réseau. Sur chaque machine, rwhod_receive: écoute les diffusions de rwhod_send sur le réseau et sauvegarde les données reçues dans un fichier local sur sa machine. ruptime lit le fichier local, affiche les informations demandées. Remarques: Il n'y a pas d'interaction directe entre ruptime et les rwhod's : la communication passe par des fichiers. Les rwhod's communiquent sans connexion et utilisent la diffusion. Tous les rwhod jouent le même rôle: chacun fait quelque chose pour les autres. Un rwhod n'attend pas une requête d'un autre rwhod pour calculer et diffuser la charge de sa machine Mais il attend les messages en provenance des autres rwhod's et sauvegarde les informations reçues dans un fichier local. Un rwhod n'attend pas une requête d'un autre rwhod pour calculer et diffuser la charge de sa machine Mais il attend les messages en provenance des autres rwhod's et sauvegarde les informations reçues dans un fichier local. => Ceci n'a rien à voir avec le modèle client/serveur. Ceci est vrai si on considère rwhod comme un tout; mais si on considère rwhod comme constitué de deux parties, on pourrait considérer rwhod_receive comme un serveur et les rwhod_send's comme des clients. rwod_receive attend de recevoir des messages pour faire quelque chose, à savoir sauvegarder la charge dans un fichier local. Ceci est vrai si on considère rwhod comme un tout; mais si on considère rwhod comme constitué de deux parties, on pourrait considérer rwhod_receive comme un serveur et les rwhod_send's comme des clients. rwod_receive attend de recevoir des messages pour faire quelque chose, à savoir sauvegarder la charge dans un fichier local. 23 sur 25 01/06/ :27

24 Cette façon de structurer une application s'appelle modèle diffusion/collection. Comparaison utilisation des ressources: Client/server: les ressources sont consommées uniquement à l'instant où les informations sont demandées. Diffusion/collection: d'autres ressources sont nécessaires car le service est assuré en permanence, même en l'absence de requêtes. Pour N accès simultanés au service: client/server: N activations de la relation client/server Diffusion/collection: pas de coût: l'information est déjà disponible partout. Terminaison: client/server: cfr. previously diffusion/collection: les rwhods ne se terminent jamais ruptime se termine quand il atteint la fin du fichier Que se passe-t-il en cas d'erreur? client/server: timeout: sans réponse après un d appelé "timeout", le client abandonne diffusion/collection: l'information sauvegardée dans le fichier local peut être obsolète. Processus serveurs Si une machine tombe en panne, l'information relative à cette machine et sauvegardée dans chaque fichier local ne disparaît pas par miracle: elle est toujours accessible par le programme ruptime Si une machine tombe en panne, l'information relative à cette machine et sauvegardée dans chaque fichier local ne disparaît pas par miracle: elle est toujours accessible par le programme ruptime Les deux modèles sont basés sur l'existence d'un serveur spécifique, respectivement rstatd et rwhod. Structure d'un serveur: boucle infinie attendre un événement; faire quelque chose; attendre à nouveau; 24 sur 25 01/06/ :27

25 durée de vie du serveur==durée de vie globale du système Un serveur n'a pas besoin de terminal: rien à lire du clavier ni à afficher à l'écran pas de caractères de contrôle à recevoir du clavierl (comme <ctrl>-c). Les processus UNIX qui ne sont associés à aucun terminal sont baptisés des : DEMONS 25 sur 25 01/06/ :27