Parallel Virtual Machine
# Parallel Virtual Machine

Parallel Virtual Machine (PVM) est un ensemble de bibliothèques logicielles et outils libres de communication (langages C et Fortran) pour machines parallèles et réseau d'ordinateurs (locaux ou distants, éventuellement hétérogènes). Il permet d’agréger un réseau d'ordinateurs en un seul ordinateur virtuel permettant ainsi d'augmenter la concurrence des calculs, d'où l'appellation de (machine virtuelle parallèle). Il a été développé au Laboratoire national d'Oak Ridge en 1989 et a servi de base à un projet plus vaste commun à trois universités des États-Unis.

## Introduction

PVM est une bibliothèque portable de passage de messages permettant d'utiliser un réseau de machines hétéroclites (ordinateur portable, PC, serveur, superordinateur) en formant une machine virtuelle unique.

Le but général de PVM est de proposer une solution simple et hautement productive pour développer des applications fortement partagées.

PVM gère tout le routage de messages, la conversion de données et la répartition des tâches au sein d'un réseau d'architectures distinctes et normalement incompatibles.

L'interface de programmation est très simple :

* l'utilisateur écrit une application comme une collection de tâches coopératives ;
* les tâches accèdent aux ressources PVM à travers une bibliothèque de routines standards ;
* ces routines permettent l'initialisation et l'exécution des tâches à travers le réseau ainsi que les communications et les synchronisations entre les différentes tâches.

## Le démon PVM (pvmd)

Un démon PVM est lancé sur chaque machine pour former une machine virtuelle globale. Un pvmd possède un propriétaire qui est le seul à pouvoir utiliser les ressources de la machine, pour des raisons de sécurité.

Le démon PVM fournit plusieurs fonctionnalités :

* authentification ;
* routage et contrôle des messages ;
* contrôle de processus ;
* détection des erreurs.

Il vérifie également si les autres démons de la machine virtuelle sont toujours en activité.

Même si l'application crashe, le démon continue de fonctionner afin d'assister le débogage.

Au démarrage, le démon se configure comme maître ou esclave selon les arguments. Il crée une grille de connexion pour communiquer avec les tâches et les autres démons, et ouvre un journal d'erreurs.

Un démon maître lit le fichier hôte s'il existe alors que le démon esclave reçoit les paramètres du maître (ce fichier est un .pvmrc dont chaque ligne est : add <nom_du_client> )

Après configuration, le démon lance une boucle qui examine toutes les sources d'entrée et place les paquets dans une file d'attente. Ces paquets sont ensuite réassemblés et injectés dans le point d'entrée.

Le démon est stoppé quand il est supprimé de la machine virtuelle ou quand il reçoit un message d’arrêt.

Quand le démon s'arrête, il effectue deux actions finales :

* il arrête les tâches sous son contrôle (avec un SIGTERM) ;
* il envoie un message à tous les autres démons dans sa table des hôtes.

Le nombre de tâches qu'un démon peut gérer est limité par deux facteurs :

* Le nombre de processus que le système d'exploitation autorise à un utilisateur ;
* Le nombre de descripteurs de fichier disponibles (dépend du système d'exploitation).

## L'interprète PVM (pvm)

Il y a un interprète, qui se lance avec la commande pvm, et qui permet d'agir sur le démon (pvmd) grâce à diverses commandes :

* conf liste l'ensemble des machines disponibles ;
* add permet de rajouter un client ;
* del permet de supprimer un client ;
* halt sort de l'interprète et tue le démon.

## La bibliothèque PVM

La bibliothèque permet à une tâche de communiquer avec le démon et les autres tâches. Elle contient des fonctions pour assembler et désassembler les messages, et d'autres fonctions pour effectuer les appels systèmes.

la bibliothèque est construite en deux niveaux :

* haut niveau générique pour toutes les machines incluant la plupart des fonctions de l'interface ;
* bas niveau spécifique à un environnement pouvant être remplacé.

## Protocoles utilisés par PVM

Les démons communiquent entre eux par UDP en utilisant un mécanisme de vérification et de récupération. TCP n'est pas utilisé dans ce cas car il consomme un FileDescriptor pour chaque connexion (nombre limité par le système) et ne permet pas de tolérance aux pannes si un démon a crashé. TCP serait également trop gourmand niveau ressource car chaque démon devrait avoir N-1 sockets, ce qui représenterait N*(N-1) sockets pour le système global.

Les tâches communiquent entre elles par le protocole TCP afin d'assurer la cohérence des données.

## Architectures supportées

Architectures supportées :

| Architecture | Système |
| - | - |
| Pentium II, Pentium Pro, Pentium, Duals and Quads | Win95, NT 3.5.1, NT 4.0 Linux, Solaris, SCO, NetBSD, BSDI, FreeBSD |
| MAC | NetBSD |
| Amiga | NetBSD |
| SUN3, SUN4, SPARC, UltraSPARC | SunOS, Solaris 2.x |
| IBM RS6000, J30 | AIX 3.x, AIX 4.x |
| HP 9000 | HPux |
| DEC Alpha, Pmax, microvax | OSF, NT-Alpha |
| SGI | IRIS 5.x, IRIS 6.x |
| Cray YMP, T3D, T3E, Cray2 | |
| Convex Exemplar | |
| IBM SP2, 3090 | |
| NEC SX-3 | |
| Fujitsu | |
| Amdahl | |
| TMC CM5 | |
| Intel Paragon | |
| Sequent Symmetry, Balance | |
