Le choix du serveur Le fonctionnement : client - maître - esclave ypbind

Le fonctionnement

Maintenant nous étudions comment les clients et les serveurs travaillent ensemble. Pour illustrer le propos, prenons l'exemple d'un utilisateur qui lance la commande ls -l.

Les fonctions appelées peuvent être représenté de la façon suivante :

1. La commande ls doit trouver le nom d'utilisateur qui correspond à l'UID du propriétaire de chaque fichier. Le processus fait donc appel à la fonction getpwuid(UID).
2. Le fichier local passwd est parcouru, mais ne contient pas l'UID cherché. Or la concaténation de la table NIS est signalée par l'entrée +::0:0:::, getpwuid() utilise donc NIS.
3. getpwuid() prend le nom de domaine par défaut et lie le processus courant à un serveur de ce domaine. ypbind fournit la liaison courante avec le domaine par défaut après avoir vérifié que le serveur n'est pas en panne. Si un autre domaine est spécifié, alors ypbind localise un serveur de ce domaine et fournira la nouvelle liaison.
4. Le processus client invoque la procédure de recherche RPC avec l'argument clé=UID et table=passwd.byuid. La requête est encodée au format XDR et envoyée au ypserv du serveur lié.
5. Le serveur traite la requête et retourne l'entrée du fichier passwd si elle existe à getpwuid(). Celle-ci retourne la donnée à l'application cliente.

Toutefois un serveur peut retourner des erreurs suite à une requête pour cause d'entrée non trouvée ou de table non existente.

À un niveau plus bas, les RPC peuvent générer des erreurs d'expiration de temps de garde comme nous l'avons évoqué plus haut. Elles surviennent lorsque le serveur répond trop lentement ou lorsqu'il n'est plus en mesure d'assurer les services (congestion, panne). Une autre raison est que les RPC de NIS utilisent le protocole de transport UDP, qui n'est pas sûr, et donc des messages peuvent se perdre.

Les RPC renouvellent alors leurs requêtes au serveur : «nouvelle chance», tout ce mécanisme restant transparent pour le processus utilisateur. Pour cela, le client doit se lier à nouveau avec le serveur du domaine. Or nous savons que ypbind retourne l'identité du serveur assurant la liaison courante.

Pour éviter une situation de blocage si ce serveur est en panne, ypbind vérifie sa «santé», par un «ping» (à ne pas confondre avec l'instruction UNIX), avant de retourner son identité au client. Il essaiera de le joindre pendant un temps et si le serveur ne répond pas, alors ypbind exécutera une nouvelle diffusion pour satisfaire le processus client qui est en attente.

Il est donc nécessaire que le service NIS soit suffisamment fiable pour que tous les clients puissent être servis. Répartir la charge sur plusieurs serveurs permettra, en cas de congestion de l'un d'eux, de ne pénaliser qu'un petit nombre de clients.

Le choix du serveur Le fonctionnement : client - maître - esclave ypbind