ARA devoir - Le site de David Averbouch

Averbouch David
ARA
Vendredi 6 novembre
AN APPROACH FOR RENDERING RING-TOKEN BASED
ALGORITHMS TOLERENT TO FAILURES
Questions
1.a) Considérez la Figure 1(c) à l’instant t1. Supposez alors que les sites S5 et S6 tombent en pannes à
l’instant t2. Quelle est la nouvelle configuration de T à t2 ? Supposez maintenant qu’à l’instant t3 le site qui
a le token (REAL) le libère. Quelle est la nouvelle configuration de T à t3 ?
A l’instant t1 le noeud4 envoi aux noeuds 5, 6, 7 et 8 la valeur de T = {S5, S6, S7, S8}. Dans ce modèle
S5 devient donc le noeud actif (REAL) et les autres les sauvegardes (BACKUP), toutefois à l’instant t2 S5 et
S6 crash ! :
- si le crash est intervenu avant Update(T) et UpdateDetection(D) ces 2 noeuds vont être suspectés et
S7 va devenir le noeud actif et après la mise a jour T = {S7, S8, S9, S10}
- si le crash survient après les mises à jour, T à l’instant t2 restera inchangé par rapport à t1 vu que le
noeud possédant le jeton a crashé
Dans cette situation, lorsque le site i libère le token (REAL), il envoi au (k+1) successeurs le message.
Il peut l’envoyer à un noeud mort ou à un noeud actif, dans tous les cas à l’instant t3 T = {Si, ... , S(i+k+1)}.
Il n’y a aucun changement dans le fait que certains de ces noeuds peuvent avoir crashé.
2) On a considéré que le système est synchrone et que les canaux de communications sont fiables. Estce que l’algorithme marcherait si on considérait que le système est asynchrone ou partiellement synchrone?
Est-ce qu’il marcherait sur un système synchrone mais avec des canaux non fiables ? Justifiez vos réponses.
Si le système est asynchrone, rien ne peux indiquer si un noeud n'émet pas car il est mort ou parce
qu il a pas encore traité (ou reçu ) le message précédant ou que son message n’ est pas en transit. Dans ce cas
là on risquerait de déclarer N-1 noeuds crashés, et donc ne pas respecter l’algorithme stipulant k < N-1 .
Un système partiellement synchrone ne pourra éviter cela car les bornes ne peuvent pas être parfaitement
calibré à l’avance , si les bornes de synchronisme sont trop petites on risquerait de retomber dans le modèle
asynchrone.
Si le système est synchrone et les canaux non fiables, l’algorithme ne pourra tout de même pas fonctionner, le
seul risque est de dénoncer des noeuds actif en noeuds morts :
un noeud mort ne peut envoyer de messages (correct ou erroné) car le crash est définitif on ne
risque donc pas de réveiller les morts !
un noeud actif peut quand a lui envoyer un message corrompu ne pouvant pas être traité par le
destinataire ce qui reviendrait a déclarer ce noeud comme mort
On pourra donc connaitre tout les véritable noeuds morts, le risque étant de croire que des vivants sont
morts ce qui peut avoir pour conséquence dans un cas qui devrait marcher de faire rater l algo :
supposons 5 noeuds, 3 actifs(A) et 2 crashés(C) avec k = 2 tel que A - A - C - C - A
Dans cet exemple si le 2eme ou dernier noeud était considéré comme mort, l’algo serait faux !
3) Est-ce que l’algorithme tolère plus de k fautes? Justifiez votre réponse.
Oui, en réalité l’algorithme ne tolère pas plus de k fautes consécutives, mais accepte, en reprenant la
notation précédente, cet anneaux : A - A - C - C - A - C - C - A - C - C - A
avec k = 2 et 6 noeuds morts
!
4) Quelle est l’avantage de l’approche proposée dans l’article par rapport à cette seconde solution ?
L’avantage est qu’il y a moins de noeuds à surveiller donc moins d’échange de message et moins de
synchronisation, par exemple : S0 - S1 - S2 - S3 , tous les noeuds sont surveillés par les 3 autres.
De plus qui peut le plus peut le moins, autrement dis un algorithme basé sur un anneau peut être porté sur
un réseau étoilé juste en ordonnant les étoiles.
5) L’algorithme considère qu’un site utilise un mécanisme de diffusion fiable pour envoyer le jeton à
k+1 sites. Cela est-il vraiment nécessaire? Est-ce que la diffusion fiable pourrait être remplacée par l’envoi
de message point a point? Justifiez votre réponse.
Le principe de la diffusion fiable dis que tous les récepteurs reçoivent ou alors aucun ne reçois, il ne
peut pas y avoir juste une partie de messages transmis, cela est nécessaire pour maintenir une vue
d’ensemble, un noeud qui crash doit être mort aux yeux de tous les autres noeuds. Si l’on utilisait l'envoi
point a point, un émetteur pourrait mourir entre 2 envois de messages cela impliquerait que le premier
verrait l'émetteur alors que les autres non, si le premier reçoit le token(REAL) il pensera que les BACKUP
sont derrière lui, ERREUR et tous peux crashé a partir de là !