4.3.2 Serveurs Multithread
Pour la création des deux serveurs principaux
multithread de l'API_IPsec, on utilise les fonctions de création de
threads du standard POSIX, les Pthreads, qu'offre Linux de manière
gratuite1. Le serveur server_main_apps fait la connexion avec les
applications utilisant par défaut le PORT_APPAPI 5010 et l'adresse IP de
l'interface 0 de la machine où il s'exécute. De même
manière, le serveur server_main_rems fait la connexion avec les
API_IPsec distantes utilisant par défaut le PORT_APIAPI 5011 et la
même adresse IP. L'API_IPsec doit bien créer et exécuter
les deux serveurs principaux pour
1 La librairie de
pthreads a été développée l'année 1995 par
l'IEEE, donc pour les utiliser il fallait payer une taxe. Puis, l'année
1998 le MIT a développé les pmpthreads avec presque les
mêmes fonctions. Enfin, pour Linux il existe depuis 2003 une version GNU
qui est la qu'on utilise dans ce projet.
|
Etude d'IPsec
Projet d'une API_IPSEC pour
la Mobilite et le Multihoming
|
|
|
avoir un fonctionnement correct. Pour cette raison,
on a développé un protocole synchronisé qui annule le
lancement de l'API_IPsec lorsque l'un ou l'autre des serveurs ne se lance pas.
On reviendra plus tard sur ce point.
Un fois les serveurs initialisés, chacun entre
dans une boucle oil écoutent et acceptent les connexions. Ils
créent un serveur dédié, soit un server_app soit un
server_rem, pour servir chaque connexion acceptée et ainsi traiter les
messages et réaliser les opérations que lui demandent. Ces
serveurs dédiés sont aussi threads qui sont registrés et
contrôlés par le thread principal père. Il peut avoir un
maximum de MAX_APPLICATIONS threads server_app et de MAX_REMOTES threads
server_rem.
Dans la définition de l'API_IPsec on a
cité comme une des principales limitations pour cette première
version la gestion de données partagées entre les
différents threads. La solution drastique prise a été de
limiter le nombre maximum d'applications et d'API_IPsec distantes à
un.
Figure 21. Exemple du serveur thread principal
"app_main_server" et de ses serveurs threads dédiés
"server_appi"
Ensuite on détaille dans le schéma
suivant le protocole de création de serveurs principaux. En effet,
l'API_IPsec doit bien créer les deux serveurs et de manière
synchronisé. Pour cela, on s'appuie sur la création d'une
variable global « contmain », d'une variable de condition
«contmain_cv» et d'une variable mutex « contmain_mutex »
(un sémaphore). La première permet d'envoyer signaux entre les
différents threads ou de les attendre. La deuxième sert à
pouvoir accéder à la variable global ou à la variable de
condition de manière unique et sans problèmes de collisions avec
les autres threads qui peuvent aussi les utiliser. Alors, le protocole suit
l'ordre suivant : une phase d'initialisation, avec l'établissement des
sockets d'écoute des deux serveurs ("socket & bind" du
server_main_apps, puis du server_main_rems). À chaque étape de
l'initialisation, des messages sont remontés grâce aux signaux. Si
les connexions s'établissent correctement ils s'autorisent l'un à
l'autre d'accéder à la boucle d'acceptations d'applications ou
d'API_IPsec distantes. Par contre, au moindre problème de connexion, les
deux serveurs principaux sont annulés.
|
Etude d'IPsec
Projet d'une API_IPSEC pour
la Mobilite et le Multihoming
|
|
|
Après la création des serveurs
principaux, le processus d'API_IPsec reste dans une boucle oil il attend les
signaux soit des serveurs principaux soit des serveurs dédiés. Si
un signal reçu est dû à la bonne initialisation des
serveurs principaux on l'ignore. Si un signal reçu de part des serveurs
dédiés indique RESTART (par exemple à cause d'une
synchronisation important due à un changement d'adresse) il faut annuler
tous les threads (dans cette première version, maximum on annulera 4
threads : deux serveurs principaux et deux dédiés), obtenir la
nouvelle adresse IP et démarrer la création des serveurs
principaux. Puis, n'importe quel autre message fait quitter l'API_IPsec, soit
un EXIT pour attendre la bonne finalisation des threads, soit un signal inconnu
ou de mal initialisation des serveurs principaux qui forcera l'annulation des
threads.
Voici le schéma :
Figure 22. Protocole de création et maintenance
des serveurs principaux
|
Etude d'IPsec
Projet d'une API_IPSEC pour
la Mobilité et le Multihoming
|
|
|
| 
