OdpornoÅÄ na bÅÄdy bizantyjskie w systemach peer-to-peer - Instytut ...
OdpornoÅÄ na bÅÄdy bizantyjskie w systemach peer-to-peer - Instytut ...
OdpornoÅÄ na bÅÄdy bizantyjskie w systemach peer-to-peer - Instytut ...
Create successful ePaper yourself
Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.
4.5 Zatwierdzanie stanu 79<br />
0<br />
1<br />
2<br />
3<br />
s 3<br />
s 0<br />
s 1<br />
s 2<br />
{s 0 , s 1 ,s 2 ,s 3 }<br />
Rysunek 4.7: Przebieg z lokalnym zapamiętywaniem stanu przez repliki. Po<br />
ponownym podłączeniu czwarta replika nie jest w stanie odzyskać sprawności.<br />
czwarta będzie odświeżo<strong>na</strong>? Niestety nie moż<strong>na</strong> tak postąpić z powodu braku<br />
zaufania, do którejkolwiek z replik. Oczywiście replika, która uległa awarii<br />
ufa samej sobie, dlatego stan s 3 , którym replika dysponuje jest akcep<strong>to</strong>walny<br />
przez nią samą, jed<strong>na</strong>kże <strong>na</strong>wet po odczytaniu stanu s 3 <strong>na</strong>dal będą niedostępne<br />
zlecenia, które przeprowadzą s 3 do aktualnie obowiązującego stanu. Brakujące<br />
zlecenia mogłyby być pobrane od repliki o numerze zero, jed<strong>na</strong>k sytuacja przedstawio<strong>na</strong><br />
<strong>na</strong> rys. 4.7 jest tylko specyficznym przypadkiem. Mogłoby się zdarzyć,<br />
że ostatni zatwierdzony stan przez replikę odbył się w czasie, gdy replika trzecia<br />
uległa awarii, wtedy zleceń nie udałoby się odzyskać.<br />
W pro<strong>to</strong>kole BFT pokazano, że zatwierdzanie stanu musi odbywać się w<br />
sposób koordynowany. Częs<strong>to</strong>ść zatwierdzania powin<strong>na</strong> być dopasowa<strong>na</strong> do<br />
obciążenia. Zatwierdzenie stanu powinno odbywać się tak częs<strong>to</strong>, jak jest <strong>to</strong><br />
możliwe, jed<strong>na</strong>k, nie <strong>na</strong> tyle częs<strong>to</strong>, by w z<strong>na</strong>cznym s<strong>to</strong>pniu obciążać usługę.<br />
Z drugiej strony zatwierdzenie stanu nie może być za rzadkie, gdyż może <strong>to</strong><br />
doprowadzić do załamania usługi w przypadku awarii. Generalnie problem częs<strong>to</strong>ści<br />
wykonywania migawek <strong>na</strong>leżałoby rozwiązać budując odpowiednie prawo<br />
sterowania, co mogłoby stanowić osobne opracowanie i w tej pracy zostało tylko<br />
zasyg<strong>na</strong>lizowane.<br />
Sterowanie czasem zapisu migawki. Przez pojęcie stanu usługi będziemy rozumieli<br />
stabilną migawkę 13 obiektu oraz wszystkie zlecenia, które jeszcze nie<br />
zostały wyko<strong>na</strong>ne. Nie uwzględniamy komunikatów, które z<strong>na</strong>jdują się w ka<strong>na</strong>łach<br />
komunikacyjnych i nie zostały potwierdzone przez większość replik.<br />
Możliwe są dwa podejścia wynikające z założenia, jak uwzględniamy czas<br />
potrzebny do wyko<strong>na</strong>nia zapisu stanu:<br />
1. Czas odzyskania stanu usługi jest mały w porów<strong>na</strong>niu do czasu wyko<strong>na</strong>nia<br />
zleceń - migawki war<strong>to</strong> wykonywać, jak <strong>na</strong>jczęściej.<br />
13 Czyli obiekt nie będący podczas tranzycji stanu wewnętrznego (wyko<strong>na</strong>nia).