4.5.3.2 Détection des liens critiques
Les Figure 4.16 et 4.17 montre des résultats similaires dans le cas de la dé- tection de liens critiques. On peut voir que, comme dans le cas de la détection de n÷uds critiques, les algorithmes localisés pour la détection de liens critiques donnent d'excellents résultats puisqu'avec une connaissance à 3 sauts, on arrive à une précision supérieure à 80 % quelque soit la densité du réseau. On observe éga- lement que les résultats obtenus par l'algorithme à 2 sauts restent très intéressants ce qui permettra de les utiliser ecacement dans la prédiction de partitionnement.
0 20 40 60 80 100
2 4 6 8 10 12 14 16
Rapport de detection
Densite
Algorithme a 1 saut Algorithme a 2 sauts Algorithme a 3 sauts
Fig. 4.16 Rapport de détection des liens critiques.
4.6 Performance des algorithmes d'évaluation pour
0 2 4 6 8 10 12 14 16 18 20
2 4 6 8 10 12 14 16
Nombre de liens critiques
Densite
Algorithme global Algorithme a 1 saut Algorithme a 2 sauts Algorithme a 3 sauts
Fig. 4.17 Nombre moyen de liens critiques dans le réseau.
3. Il existe un chemin sans boucle entreu etv qui contient un n÷ud critique.
Après analyse, il s'avère que la méthode basée sur les n÷uds critique doit être modiée pour être vraiment ecace. En eet, comme le montre la Figure 4.18, la présence d'un n÷ud critique sur un chemin reliant le client au serveur n'est pas forcement signe de faiblesse car ce n÷ud peut séparer le graphe en deux composantes tout en conservant le client et le serveur dans la même.
La méthode 3 doit donc être améliorée pour prendre en compte ce genre de situation qui mènerait à une prédiction erronée. La proposition suivante corrige le problème :
On noteCCu(v)l'ensemble des n÷uds qui appartiennent à la même compo- sante connexe quevquand le n÷uduest retiré. Il y a risque de déconnexion s'il existe un chemin sans boucle entreuetvqui contient un n÷ud critiquew tel que son prédécesseur xet son successeur ysatisfontCCw(x)6=CCw(y). La propriété CCw(x) 6= CCw(y) est facilement évaluable localement car elle revient à chercher s'il existe un chemin entre x et y qui n'utilise pas le n÷ud w. S'il n'y en a pas, x et y n'appartiennent pas à la même composante connexe (privée de w).
D'un point de vue pratique, et an de diminuer les alertes non pertinentes, nous introduisons dans l'algorithme de prédiction un timeout. L'alerte ne sera alors donnée que si l'évaluation atteint son seuil critique pendant un temps égal
Client
Serveur Noeud Critique
Routes disponibles
0000 0000 1111 1111
0000 0000 1111 1111
0000 0000 1111 1111
Fig. 4.18 Un n÷ud critique n'est pas forcement signe de faiblesse.
au timeout. En eet, il est fréquent que l'évaluation atteigne son seuil d'alerte de façon ponctuelle pour remonter à une valeur reétant une abilité susante. La valeur de ce timeout sera également évaluée.
An de comparer les trois méthodes, nous allons observer deux paramètres, l'ecacité, c'est à dire le nombre de déconnexions prédites avec succès, et le temps existant entre la prédiction et la déconnexion eective. Ce temps sera mis en rapport avec le temps total pendant lequel le client et le serveur auront été connectés.
Les paramètres de simulation sont une densité de 8 n÷uds par zone de com- munication et une vitesse de 2 mètres par seconde. La densité est choisie car elle correspond à un réseau moyennement dense dans lequel les partitionnement du réseau peuvent arriver régulièrement. Choisir une densité plus important entraîne très peu de déconnexions. La vitesse corresponds quant à elle à la vitesse d'une marche rapide, ce qui se place dans le cadre de notre étude, à savoir des piétons à l'intérieur d'un bâtiment. Le nombre de n÷uds est toujours xé à 500.
Les Figures 4.19 et 4.20 nous permettent de choisir une valeur de timeout ef- cace pour les diérentes méthodes. La première observation que l'on peut faire est que les trois méthodes d'évaluation orent des résultats relativement simi- laires. Ceci peut s'expliquer par la forte corrélation existant entre les diérentes méthodes d'évaluation, en particulier dans le cas des chemins n÷ud-disjoints et des n÷uds critiques qui sont montrées équivalentes par le théorème de Menger.
Les diérences entre ces deux dernières méthodes s'expliquent simplement par le fait que les algorithmes utilisés pour récupérer l'information nécessaire ne sont pas globaux et ne fournissent donc qu'une approximation de la réalité.
Concernant le timeout, comme on pouvais s'y attendre, la valeur du temps de déclenchement de l'alerte inue pour beaucoup dans l'ecacité de la prédiction
0 20 40 60 80 100
0.5 1 1.5 2 2.5
Efficiency (%)
Timeout Critical links
Critical nodes Disjoint Paths
Fig. 4.19 Écacité des méthodes de prédiction en fonction de la valeur du timeout
0 20 40 60 80 100
0.5 1 1.5 2 2.5
Alert (%)
Timeout Critical links
Critical nodes Disjoint Paths
Fig. 4.20 Temps passé en alerte en fonction de la valeur du timeout
ainsi que dans la pertinence des alertes. Pour qu'un algorithme de prédiction soit performant, il faut bien évidement qu'il soit able, c'est à dire que l'ecacité soit proche de 100 %, mais il faut aussi qu'il ne prédise pas de déconnexion quand cela n'est pas nécessaire. Il est en eet aisé de dénir un protocole naïf qui aurait une ecacité totale. Il sut de signaler une alerte dès le début de la connexion entre le client et le serveur. Il va de soi qu'une telle méthode n'est pas du tout utilisable.
La prédiction doit donc être donnée peu de temps avant la déconnexion.
On observe que le plus petit temps passé en alerte2 tout en conservant une abilité correcte (au delà de 80 %) est situé aux alentours de 50 % du total de connexion total en utilisant un timeout compris entre une seconde et une seconde et demi. Cette valeur peut paraître importante au premier abord. Cependant, il ne faut pas oublier qu'il faut laisser du temps aux applications pour réagir à une éventuelle déconnexion. En fonction de la solution retenue pour la réaction, le temps nécessaire peut s'avérer être important, par exemple pour la réplication d'un service de taille importante. Dans cet optique, le temps d'alerte peut être jugé correct.
Néanmoins, il serait bien évidement intéressant de pouvoir quantier le temps restant aux applications pour réagir. Grâce à la Figure 4.21, nous donnons un premier éléments de réponse sur ce point. Nous avons observé la distribution des temps observés entre la prédiction et la déconnexion sur l'ensemble de nos expériences.
Nous pouvons donc, à l'heure actuelle, construire par simulations des abaques permettant de fournir une estimation sur le temps qu'aurait une application pour réagir après l'alerte. Dans le cas de la Figure 4.21, nous pouvons énoncer qu'en moyenne, à densité 8 pour une vitesse de 2 mètres par seconde, il y a une chance sur deux pour que la déconnexion interviennent au maximum 50 secondes après l'alerte.